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ABSTRACT 


The  term  probe  effect  denotes  behavioral  changes  caused  by  introducing  delays  into 
a  concurrent  program  with  synchronization  errors.  This  thesis  investigates  the  feasibility  of 
developing  discrete-event  simulation  (DES)  models  of  software  architectures  to  perform 
software  testing  free  of  the  probe  effect. 

A  message-passing  subsystem  (MPS)  and  simulated  MPS  (SMPS)  were  developed 
in  Java  that  runs  with  the  same  application  code.  An  MPS  platform-performance  model 
(MPPM)  was  developed  using  dual-loop  benchmarking  and  was  integrated  into  the  SMPS. 
Two  demonstration  programs  were  developed  to  study  SMPS  timing  and  its  model  of  a 
preemptive  multi-threaded  run-time  system.  The  SMPS-based  program  behavior  was  com¬ 
pared  to  hypothetical  execution  on  a  platform  with  a  perfect  system  clock  and  no  execution 
overhead. 

The  differences  between  hypothetical  and  observed  SMPS-based  execution  were 
found  to  correctly  reflect  the  MPPM.  The  results  indicated  that  it  is  feasible  to  develop  DES 
implementations  of  some  software  architectures  to  perform  software  testing. 
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I.  INTRODUCTION 


Concurrent  programs  are  used  increasingly  in  modern  software  systems.  Modem 
high-level  programming  languages  such  as  Java  and  Ada  have  facilities  for  concurrency 
control  built  into  the  language.  This  provides  the  opportunity  to  develop  transportable  con¬ 
current  programs.  Such  programs  must  often  meet  timing  requirements  and  are  typically 
more  complex  than  their  sequential  counterparts.  More  frequent  design  and  implementation 
errors  usually  accompany  additional  complexity.  More  and  better  software  testing  can  re¬ 
duce  this  problem.  However,  invasive  testing  techniques  that  save  or  display  program  state 
can  change  timing  in  concurrent  programs  by  consuming  additional  CPU  time  and  by  al¬ 
tering  synchronization  relationships  with  operations  such  as  10  blocking,  preemption,  or 
breakpointing.  The  term  probe  effect  denotes  behavioral  changes  caused  by  introducing  de¬ 
lays  into  a  concurrent  program  [Gait  1986;  McDowell  and  Helmbold  1989;  Fidge  1993; 
Shutz  1993].  The  probe  effect  presents  a  serious  challenge  to  software  testers  since  it  can 
cause  a  program  to  generate  different  results  depending  on  whether  it  is  being  tested. 

A.  RESEARCH  QUESTIONS 

The  thesis  is  concerned  with  two  questions  related  to  avoiding  the  probe  effect  in 
testing  real-time  software  implemented  in  high-level  languages  (HLL)  developed  using 
Object-Oriented  Analysis  (00 A).  The  uniprocessor  question  is  whether  it  is  feasible  to  de¬ 
velop  a  simulation  model  of  an  application-independent  software-architecture  and  environ¬ 
ment  in  which  to  execute  the  same  (HLL)  application-level  binary  code  as  would  execute 
in  the  target  environment.  The  distributed-systems  question  is  whether  it  is  feasible  to  de¬ 
velop  such  an  approach  to  support  execution  of  distributed  real-time  applications. 
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The  capability  to  execute  the  same  HLL  application  code  in  both  a  simulation  mod¬ 
el  and  in  its  target  environment  would  enable  application-level  software  testing  to  be  con¬ 
ducted  under  controllable  conditions  free  of  the  probe  effect.  Implementations  of  the  same 
software  architecture  (SA)  that  generate  the  same  program  results  with  the  same  applica¬ 
tion-level  binary-code  have  application-binary-code  consistency  (ABCC).  The  require¬ 
ment  that  the  same  application  code  execute  in  both  environments  implies  that  both 
implementations  have  ABCC  and  that  they  have  the  same  interface.  If  the  software-archi¬ 
tecture  were  free  of  application-content,  it  would  yield  a  reusable  software-architecture  for 
testing  and  executing  real-time  applications.  Having  a  capability  that  relied  only  on  a  single 
HLL  for  timing  and  synchronization  would  produce  highly  portable  and  testable  software. 
Both  the  simulation  model  and  the  application  software  for  the  target  system  would  be  in¬ 
dependent  of  the  operating  system  and  hardware  platform. 

The  capability  to  execute  distributed  real-time  applications  in  both  environments 
supports  the  testing  of  multiple  communicating  application  instances  under  conditions  that 
are  free  of  the  probe  effect.  This  would  enable  software  testers  to  cover  previously  unat¬ 
tainable  test  cases  by  increasing  the  amount  of  control  they  have  over  the  test  environment 
for  distributed  systems. 

B.  METHODOLOGY 

As  part  of  the  investigation  presented  in  this  thesis,  two  implementations  of  the 
same  software-architecture  were  developed.  The  first  is  an  object-oriented,  multi-threaded, 
asynchronous,  message-passing  subsystem  (MPS).  The  second  is  a  sequential,  discrete- 
event  simulation  (DES)  model  of  the  MPS  (SMPS). 

Two  design  goals  drove  the  development  of  MPS  and  SMPS.  First,  they  must  have 
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the  same  interface  so  that  applications,  if  properly  implemented,  can  execute  unmodified 
on  both.  The  SMPS  must  also  have  the  same  message  transmission  and  reception  order  as 
the  MPS  to  the  extent  that  the  MPS  run-time  environment  is  deterministic. 

Since  timing  characteristics  are  largely  a  function  of  the  run-time  environment,  the 
SMPS  was  parameterized  to  accept  a  platform-performance  model.  A  platform  perform¬ 
ance-model  acquisition  method  was  developed  using  a  dual-loop  measurement  technique 
[Clapp  et  al.  1 986;  Altman  and  Weiderman,  1 987;  Vestal,  1 990]  to  acquire  language  feature 
execution  time  estimates. 

Two  demonstration  programs  were  also  developed.  An  implementation  of  the  “Din¬ 
ing  Philosophers”  program  [Dijkstra  1971]  was  developed  to  test  the  timing  and  synchro¬ 
nization  features  of  the  simulation  model.  The  second  is  an  MPS-based  program  with  Rate 
Monotonic  Scheduling  (RMS)  priority  assignments  and  artificial  workloads  [Sha  and 
Goodenough,  1990].  This  program  was  developed  to  study  SMPS  timing  and  the  model  of 
a  preemptive  multi-threaded  run-time  system. 

C.  OVERVIEW  OF  THE  THESIS 

Chapter  II  of  the  thesis  presents  background  material  consisting  of  brief  overviews 
of  related  approaches  to  addressing  the  probe  effect,  relevant  aspects  of  DES  modelling, 
and  OOA.  Chapter  III  describes  the  operational  models  and  design  of  the  MPS  and  SMPS 
and  addresses  issues  related  to  SMPS  fidelity.  Chapter  IV  describes  platform  performance- 
model  development.  Chapter  V  presents  descriptions  of  the  demonstration  programs  and 
discusses  their  results  and  implications  for  distributed  systems.  Finally,  Chapter  VI 
presents  the  conclusions,  discusses  relevance  to  other  application  areas,  and  presents  rec¬ 
ommendations  for  further  research. 


Appendix  A  contains  the  OOA  model  diagrams  for  the  MPS  and  the  SMPS  and 
sample  OOA  model  diagrams  for  a  simulated  distributed  MPS  (SDMPS).  Appendix  B  con¬ 
tains  MPS  and  SMPS  source  code  examples.  Appendix  C  contains  the  “Dining  Philoso¬ 
pher”  OOA  model  diagrams.  Appendix  D  contains  selected  sections  of  the  execution  traces 
for  the  Dining  Philosophers  and  RMS  programs. 
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II.  BACKGROUND 


This  chapter  provides  background  on  approaches  to  addressing  the  probe  effect  and 
explains  its  significance  for  software  testing.  It  also  provides  background  on  simulation 
modelling  and  defines  the  approach  used  in  the  current  investigation.  Finally,  it  describes 
the  derivative  of  OOA  used  in  the  development  approach. 

A.  THE  PROBE  EFFECT 

Probe  effect  delays  are  delays  caused  by  intrusive  techniques  such  as  running  the 
program  in  a  debugger  and  by  source  code  instrumentation  in  testing.  Delays  may  also  be 
introduced  by  operating  system  effects  [Gait  1986]  and  by  other  sources  of  non-determin¬ 
ism  such  as  communication  protocols  [Tannenbaum  1 996].  Gait  states  that  the  probe  effect 
often  manifests  itself  in  two  ways  [Gait  1986].  Either  a  non-functioning  program  begins  to 
operate  as  desired  when  delays  are  inserted  or  an  apparently  working  program  yields  incor¬ 
rect  results  with  inserted  delays.  There  are  also  two  other  ways  the  probe  effect  can  mani¬ 
fest  itself.  One  is  when  a  program  that  previously  gave  incorrect  results  yields  different 
incorrect  results  with  inserted  delays.  The  other  is  when  a  functioning  program  gives  dif¬ 
ferent  correct  results  with  inserted  delays.  Although  this  thesis  is  concerned  with  the  probe 
effect  in  software  testing,  most  of  the  other  work  to  eliminate  or  mitigate  the  probe  effect 
addresses  its  role  in  debugging. 

Netzer  and  Miller  state  that  two  messages  in  a  message-passing  parallel  program 
can  race  if  they  are  simultaneously  in  transit  and  either  could  arrive  first  at  some  receive 
operation  [Netzer  and  Miller  1 994],  Lamport  defines  the  happened  before  relation  and  con¬ 
current  as  follows  [Lamport  1978]: 
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Definition.  The  relation  on  the  set  of  events  of  a  system  is  the 
smallest  relation  satisfying  the  following  three  conditions:  (1)  If  a  and  b  are 
events  in  the  same  process,  and  a  comes  before  b,  then  a->b.  (2)  If  a  is  the 
sending  of  a  message  by  one  process  and  b  is  the  receipt  of  the  same  mes¬ 
sage  by  another  process,  then  a->b.  (3)  If  a-^b  and  b->c  then  a-^c.  Two 
distinct  events  a  and  b  are  said  to  be  concurrent  if  —\(a—>b)  and  —t(b—>a). 

Netzer  and  Miller’s  racing  messages  are  examples  of  Lamport’s  concurrent  events. 
A  synchronization  error  exists  if  the  arrival  order  of  two  racing  messages  affects  program 
correctness  [Netzer  and  Miller  1994].  The  probe  effect  adds  to  the  risk  that  actual  test  cases 
may  not  implement  test  case  design  by  affecting  the  arrival  order  of  racing  messages. 

When  a  race  is  detected,  the  logical  time  of  the  message  receipt  is  traced,  or  record¬ 
ed.  Traced  times  accompany  racing  messages  and  during  re-execution,  message  receipt  for 
racing  messages  is  restricted  to  the  traced  time  from  a  previous  execution.  This  approach  is 
more  efficient  than  other  trace  and  replay  schemes  that  constrain  all  message  receptions  to 
traced  times.  However,  it  maintains  the  same  synchronization  properties  as  the  original  ex¬ 
ecution  by  preserving  the  happened  before  relation  [Netzer  and  Miller  1994]. 

Jain  et  al.  used  intrusive  techniques  to  monitor  timing  behavior  for  real-time  sys¬ 
tems  [Jain  et  al.,  1996].  The  approach  maintains  local  time  as  the  value  pair  {CT,  A),  where 
CT is  the  clock  time  obtained  from  the  internal  clock,  and  A  is  the  current  intrusion  time.  In 
this  case  intrusion  time  is  the  CPU  time  consumed  by  executing  the  monitoring  instructions 
on  the  same  CPU.  The  estimate  of  clock  time,  given  as  CT- A,  replaces  clock  time  in  timing 
computations.  This  prevents  the  probe  effect  from  affecting  program  results.  This  approach 
uses  a  model  of  actual  clock  time  and  requires  accurate  knowledge  of  the  timing  properties 
of  monitoring  operations. 

Reproducibility,  like  the  term  test  repeatability,  describes  whether  a  program  com¬ 
putes  the  same  results  when  repeatedly  executed  with  the  same  inputs  [Schutz  1993].  One 


6 


way  to  avoid  the  probe  effect  in  debugging  is  to  permanently  install  debugging  probes  in 
the  program  so  the  program  undergoing  debugging  is  the  same  as  the  final  version  [Mc¬ 
Dowell  and  Helmbold  1989;  Fidge  1993].  Practical  debugging  problems  attributed  to  the 
probe  effect  are  often  manifestations  of  the  difficulty  of  achieving  reproducibility  [Fidge 
1993], 

In  Timewarp,  there  is  one  local  virtual  clock  per  process  and  messages  to  be  sent 
are  timestamped  with  the  virtual  time  when  they  must  be  received.  Local  virtual  time  is  up¬ 
dated  to  the  timestamp  of  the  next  event  in  the  process  input  queue.  When  a  process  re¬ 
ceives  a  message,  m,  with  a  receive-time  that  is  earlier  than  its  local  virtual  time,  its  state 
and  local  virtual  time  are  restored  to  m’s  receive-time  and  any  synchronizing  actions  it  per¬ 
formed  since  that  time  are  undone  [Jefferson  1985], 

Tolmach  and  Appel  developed  an  interactive  debugger  with  reverse  execution  for 
the  language  Standard  ML  [Tolmach  and  Appel  1991].  This  debugger  associates  the  value 
of  a  software  instruction  counter,  a  so-called  s-time,  that  is  incremented  each  time  a  debug¬ 
ger  breakpoint  or  periodic  checkpoint  is  encountered.  Since  this  approach  was  highly  vul¬ 
nerable  to  the  probe  effect,  they  proposed  a  model  of  concurrency  debugging  based  on  the 
Timewarp  system  [Jefferson  1985],  This  proposal  includes  the  concept  of  a  virtual  multi¬ 
processor  consisting  of  a  number  of  virtual  processors.  Each  virtual  processor  would  be 
characterized  by  an  execution  rate  and  its  current  s-time  would  be  substituted  for  Time- 
warp-style  local  virtual  time.  The  system  would  compensate  for  probe  effects  by  rolling 
back  operations  that  violate  the  total  ordering  of  synchronizing  operations  as  defined  by  s- 
times.  By  varying  the  specified  number  and  execution  rates  of  virtual  processors  one  could 
obtain  data  from  different  program  runs  that  would  help  expose  time-dependent  behavior 
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[Tolmach  and  Appel  1991]. 

Huang  developed  a  software  simulator  of  a  4MHz  Z80  processor  designed  to  exe¬ 
cute  programs  in  machine  code  to  facilitate  testing  and  debugging  of  real-time  programs 
[Huang  et  al.  1983].  This  avoided  the  problem  that  traditional  debuggers  have  of  handling 
interrupts.  It  also  avoids  the  problem  that  real-time  simulators  have  of  being  required  to 
process  large  quantities  of  mostly  irrelevant  data.  This  is  another  example  of  an  approach 
that  uses  a  model  of  time  to  avoid  the  probe  effect.  Similar  approaches  are  often  used  for 
testing  real-time  control  systems. 

The  significance  of  the  probe  effect  and  unpredictable  delay  insertion  for  software 
testing  is  the  adverse  effect  on  observability  and  controllability  [Shutz  1993].  The  probe  ef¬ 
fect  adds  to  the  risk  that  actual  test  cases  may  not  implement  test  case  design.  The  goal  of 
software  testing  is  to  find  errors  and  a  successful  software  test  is  one  that  reveals  an  error 
[Myers  1979].  Debugging  has  been  described  as  diagnosis  and  correction  performed  after 
executing  a  successful  test  case  [Myers  1979;  Shutz  1993].  The  impact  of  the  probe  effect 
on  software  testing  is  more  closely  related  to  controllability  than  reproducibility,  but  the  re¬ 
verse  is  true  for  debugging. 

Gupta’s  approach  accurately  reports  timing  information  by  compensating  for  probe 
effect  intrusion  time  [Gupta  et  al.  1996].  However,  the  approach  does  not  address  reproduc¬ 
ibility  or  controllability  needed  for  testing.  Netzer  and  Miller’s  approach  requires  the  de¬ 
velopment  of  a  debugger.  This  makes  portability  costly  [Netzer  and  Miller  1994],  Tolmach 
and  Appel’s  approach  also  has  limited  portability  because  it  is  restricted  to  the  Standard 
ML  language.  Huang’s  approach  requires  development  of  a  virtual  processor  for  each  re¬ 
quired  processor  type  [Huang  et  al.  1983],  also  making  portability  a  difficult  problem.  It 
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require  access  to  the  operating  system  machine-code  for  each  target. 

The  approach  presented  in  this  work  assumes  the  existence  of  two  versions  of  a  test¬ 
ed  and  debugged  application-independent  software-architecture  and  a  performance  model 
generation  program.  Testing  the  software  on  another  platform  should  only  require  genera¬ 
tion  of  a  new  performance  model.  Actual  testing  can  be  performed  on  any  platform  that  can 
support  the  simulation  model  using  the  newly  acquired  performance  model  as  input. 

B.  DISCRETE-EVENT  SIMULATION 

Russell  defines  simulation  as  follows:  “A  simulation  of  a  system  is  the  operation  of 
a  model- that  is  a  representation  of  the  system”  [Russell  1983].  Models  of  systems  may  be 
continuous  or  discrete  depending  on  the  model  of  changes  in  system  state  [Graybeal  1 980]. 
Models  of  systems  may  also  be  stochastic  or  deterministic.  Stochastic  models  contain  a  cer¬ 
tain  amount  of  randomness.  In  deterministic  models  the  system  evolves  completely  deter¬ 
ministically  from  one  state  to  the  next  [Graybeal  1980]. 

Most  discrete  simulation  tools  have  either  a  time-driven  or  an  event-driven  clock 
(EDC)  policy.  A  time-driven  policy  usually  consists  of  repeatedly  incrementing  the  clock 
with  a  fixed  time  quantum  and  then  servicing  all  events  scheduled  to  occur  at  that  simula¬ 
tion  time.  In  such  cases,  the  time  quantum  is  the  clock  granularity.  An  EDC  policy  usually 
can  be  implemented  by  repeatedly  removing  the  event  from  the  event  set  with  the  earliest 
activation-time,  updating  the  clock  to  the  time  of  that  event,  and  then  servicing  that  event. 
Events  are  often  serviced  by  executing  an  event-subprogram.  An  event-subprogram  is  a 
subprogram  that  models  the  behavior  of  one  or  more  events  occurring  at  an  instant  in  time. 
The  Java  method  named  current,  activate  shown  in  Fig.  2.1  is  an  example  of  an  event-sub¬ 
program. 
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DES  models  may  also  be  process-oriented  or  event-activation-oriented.1  SIM- 
SCRIPT  II. 5  [Russell  1983],  Simula  67  [Birstwistle  et  al.  1973],  and  the  Ada  Process-Ori¬ 
ented  Simulation  Library  (APOSL)  [Ollerton  1992]  are  examples  of  process-oriented  DES 
systems.  Process-oriented  systems  have  a  concept  of  a  process  and  may  have  state  and  a 
lifetime.  The  process  reacts  to  events  that  may  cause  it  to  perform  an  action,  simulate  the 
passage  of  time,  become  suspended  or  interrupted,  and  so  on.  In  an  event-activation-orient¬ 
ed  system  instantaneous  events  occur  at  scheduled  times  in  a  model.  Occurrences  of  such 
events  and  the  separations  in  time  between  them  can  be  functionally  equivalent  to  the  life- 
cycle  of  a  process  in  a  process-oriented  system. 

In  general,  process-oriented  approaches  require  more  resources  than  event-activa¬ 
tion-oriented  approaches,  but  processes  are  very  convenient  modelling  abstractions  for  en¬ 
tities  with  life-cycles.  However,  they  generally  consume  more  memory  and  CPU  time  than 
event-activation-oriented  approaches  due  to  the  necessity  to  save  and  switch  execution  con¬ 
text  during  process  state  transitions. 

In  a  DES  model,  a  positive  difference  in  time  between  the  occurrence  of  two  suc¬ 
cessive  events  represents  the  passage  of  time.  It  is  commonly  used  to  represent  the  duration 
of  an  action.  A  DES-action  represents  activity  occurring  over  a  finite  positive  amount  of 

public  static  void  EDC_Loop ( ) { 
current  =  nextEvent(); 
while  (current  !=  null) { 

clock  =  clock  +  current . activation_time; 
current . activate ( ) ; 
current  =  nextEvent(); 

} 

} 

Figure  2.1.  Example  of  a  Java  Implementation  of  an  EDC  Policy 

1.  The  term  event-activation-oriented  is  used  since  there  does  not  appear  to  be  a  single  commonly 
used  term  to  describe  this  approach. 
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time  modelled  by  the  occurrence  of  two  events  denoting  the  beginning  and  end  of  the  ac¬ 
tion.  DES-action-time  is  the  difference  between  the  activation-times  of  these  events.  The 
granularity  of  DES-action-time  impacts  model  fidelity,  performance,  and  development  ef¬ 
fort  of  DES  simulation  models. 

During  this  work  a  minimal  event-activation-oriented  DES  library  with  an  EDC 
policy  was  developed  in  Java  to  support  a  deterministic  model  of  the  MPS  running  in  a  pri¬ 
oritized,  preemptive,  multi-threaded  environment. 

C.  OBJECT-ORIENTED  ANALYSIS 

Rumbaugh  states  that  the  term  object-oriented  means  organizing  software  as  a  col¬ 
lection  of  discrete  objects  that  incorporate  both  data  structure  and  behavior  [Rumbaugh,  et 
al.,  1991].  Inheritance  and  polymorphism  are  two  properties  that  are  also  associated  with 
object-orientation.  Inheritance  refers  to  the  object-oriented  property  that  when  descendents 
of  types  are  defined  through  type  extension  or  specialization  [Rumbaugh  et  al.  1991]  they 
inherit  the  characteristics  of  the  ancestor  type.  Polymorphism  describes  the  property  of  de¬ 
scendents  having  different  implementations  of  an  operation  that  is  defined  in  the  ancestor 
type.  Different  implementations  of  a  polymorphic  operation  must  have  the  same  signature, 
that  is,  the  same  number  and  types  of  arguments  and  the  same  result  type  [Rumbaugh  et  al. 
1991]. 

The  term  Object-Oriented  Analysis  was  first  used  to  denote  the  Shlaer  and  Mellor 
method  (SMM)  “for  identifying  the  significant  entities  in  a  real-world  problem  and  for  un¬ 
derstanding  and  explaining  how  they  interact  with  one  another”  [Shlaer  and  Mellor  1988]. 
This  consists  mainly  of  producing  a  set  of  information,  state,  and  process  models  by  apply¬ 
ing  the  rules  of  the  method  [Shlaer  and  Mellor  1988;  Lang  1993;  Shlaer  and  Langl996]. 
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The  term  00 A  is  now  commonly  used  to  denote  object-oriented  high-level  design  and  anal¬ 
ysis  methods  for  software  engineering. 

The  SMM  distinguishes  itself  from  other  OOA  and  object-oriented  design  ap¬ 
proaches  in  three  ways.  First,  objects  are  abstractions  of  real-world  things  in  the  application 
domain  as  opposed  to  representing  conceptual  entities  of  the  design  [Shlaer  and  Mellor 
1997],  Second,  analysis  proceeds  by  separating  systems  into  various  domains,  or  subject 
areas,  that  are  analyzed  separately.  These  are  the  application  domain,  various  service  do¬ 
mains,  the  software-architecture-domain,  and  other  architecture-domains.  Finally,  SMM  is 
a  translation-based  method,  as  opposed  to  being  elaborative  [Bell  1998].  In  an  elaborative 
method  such  as  Object  Modelling  Technique  (OMT),  object  design  is  a  process  of  adding 
detail  to  existing  models  and  making  implementation  decisions  [Rumbaugh  et  al.  1991]. 
SMM  translation  is  a  more  elaborate  process. 

SMM  translation  requires  application  analysis,  architecture,  an  application-in- 
stance-to-architecture-instance  mapping,  and  a  system-construction  engine.  SMM  analysis 
“consists  of  work  products  that  identify  the  conceptual  entities  of  a  single  domain  and  ex¬ 
plain,  in  detail,  the  relationships  and  interactions  between  these  entities”  [Shlaer  and  Mellor 
1997].  These  consist  primarily  of  a  domain  model,  an  object  information  model  (OIM)  for 
each  domain,  a  state-model  for  each  active  object  in  each  OIM,  and  an  action  data-flow  di¬ 
agram  (ADFD)  for  each  action  of  each  state-model.  An  active  object  is  an  object  with  in¬ 
teresting  behavior.  Architecture  deals  completely  with  the  following  concerns: 

•  policies  and  mechanisms  for  organizing  and  accessing  data; 

•  control  strategies,  including  synchronization,  concurrency,  interactions  in  a  dis¬ 
tributed  system,  and  the  like; 

•  structural  units-the  tasking  strategy  for  the  system,  strategies  for  allocating 
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tasks  to  processors  and  processing  units  to  tasks,  standard  structures  used  with  a 
task;  and 

•  time— mechanisms  for  keeping  time  and  for  creating  delayed  transfers  of  control. 
[Shlaer  and  Mellor  1997]. 

Archtypes  are  much  like  macros  and  provide  the  application-instance-to-architec- 
ture-instance  mapping.  “An  archtype  combines  text,  written  in  the  target  programming  lan¬ 
guage,  with  placeholders  used  to  represent  information  from  the  architecture’s  instance 
database”  [Shlaer  and  Mellor  1997].  An  instance  database  is  a  database  containing  infor¬ 
mation  about  preexisting  instances  from  the  associated  domain.  A  system-construction  en¬ 
gine  is  “a  script...  that  will  generate  the  code  for  the  system  from  the  analysis  models,  the 
archtypes,  and  the  instance  databases  of  all  domains”  [Shlaer  and  Mellor  1997]. 

SMM  translation  requires  an  architecture-independent  analysis  expressed  in  com¬ 
plete  detail  and  compliant  with  the  rules  [Shlaer  and  Mellor  1988;  Lang  1993;  Shlaer  and 
Lang  1996]  of  the  method  [Shlaer  and  Mellor  1997].  It  also  requires  an  application-inde¬ 
pendent  architecture  also  expressed  in  complete  detail  in  both  conceptual  and  archtype 
terms”  [Shlaer  and  Mellor  1997].  The  system-construction  engine  takes  the  instance  data¬ 
bases  and  analysis  models  as  input  and  expands  the  archtypes  to  produce  the  code. 

The  SMM  method  is  relatively  formal  [Shlaer  and  Mellor  1988;  Lang  1993;  Shlaer 
and  Lang  1996]  and  requires  a  considerable  investment  of  effort  to  produce  a  complete  set 
of  archtypes  for  the  architecture-domain  and  a  complete  set  of  models  for  multiple  do¬ 
mains.  This  is  likely  to  be  more  expensive  than  elaborative  approaches  for  one-time  devel¬ 
opment  efforts.  It  is  also  likely  to  be  relatively  expensive  when  applied  to  problems  with 
volatile  requirements.  In  his  summary  on  translative  approaches.  Bell  commented  that 
“The  key  determinant  is  the  potential  return  from  reusing  the  architectures”  [Bell  1998]. 
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A  complete  application  of  the  SMM  is  impractical  for  this  effort.  The  models  pre¬ 
sented  in  this  work  are  primarily  for  descriptive  purposes.  However,  the  development  ap¬ 
proach  used  in  this  thesis  is  similar  to  the  SMM  in  the  following  ways.  First,  it  views 
application  and  architecture  as  separate  analysis  problems.  Second,  objects  represent  con¬ 
ceptual  entities  in  the  analysis  domain,  as  opposed  to  design  entities.  Finally,  it  uses  state 
machines,  as  opposed  to  OMT  state-charts,  to  model  system  dynamics. 

The  SMM  defines  action  time  as  the  time  required  to  execute  a  state-model  action 
[Shlaer  and  Mellor  1992],  In  order  to  avoid  confusion  with  DES-actions  and  DES-action- 
time,  state-model  action  and  state-model  action  time  will  be  referred  to  from  here  on  as  SM- 
action  and  SM-action-time. 

Huang’s  Z80  simulator  referred  to  in  section  A  above  [Huang  et  al.  1983]  could 
have  been  implemented  as  a  DES  model  with  an  EDC  policy  and  default  granularity  of  one 
CPU  cycle.  The  three  main  capabilities  required  to  achieve  this  are  the  capabilities  to  fetch 
the  next  instruction,  to  execute  the  instruction,  and  to  update  the  clock.  Figure  2.2  shows 
how  a  hypothetical  EDC-loop  could  be  implemented  in  Java  to  achieve  this. 

This  approach  could  also  be  viewed  as  state  machine  execution.  Each  SM-action 
corresponds  to  a  DES-action  and  SM-action-time  corresponds  to  DES-action-time  from 
this  viewpoint.  This  correspondence  is  highly  desirable  because  it  allows  the  application 


public  static  void  Z80_Loop(){ 
current  =  f etchlnstruction ()  ; 
while  (current  !=  null) { 
current . execute ( )  ; 

clock  =  clock  +  current . clock_cycles; 
current  =  f etchlnstruction  () ; 

} 


Figure  2.2.  Java  Code  Fragment  of  a  Hypothetical  Z80  Simulator 
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source  code  to  execute  in  the  simulator  unchanged.  However,  it  also  requires  more  EDC- 
loop  overhead  than  the  latter  approach. 

The  portability  problems  mentioned  in  section  A  limit  the  usefulness  of  machine- 
code-level  modelling  of  programs  written  in  HLLs  with  built-in  concurrency  such  as  Java 
or  Ada.  Unfortunately,  HLL  statement-level  modelling  for  such  languages  is  likely  to  be 
unsatisfactory  for  concurrent  programs.  It  would  raise  the  level  of  abstraction  and  achieve 
greater  portability  at  the  expense  of  model  fidelity  because  single  HLL  statements  can  mask 
complicated  interactions. 

D.  DEFINITION-USE  PATHS  WITH  RESPECT  TO  THE  CLOCK 

Figure  2.3  graphically  depicts  the  views  of  time  in  SM-action  and  DES-action  exe¬ 
cution  of  the  same  n  statements.  In  each  case,  the  value  of  the  internal  clock  is  t„  after  n 
statements  have  completed  execution.  However,  after  statement  Sq  has  executed,  the  value 
of  the  internal  clock  is  tj  in  the  SM-action  and  is  still  t0  in  the  DES- Action.  In  the  SM-ac- 
tion,  each  statement  is  viewed  as  consuming  a  quantity  of  time  as  indicated  in  the  time  col- 
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for  the  SM-action.  However,  the  DES-action  time  column  shows  that  no  simulation 

elapses  between  statement  executions  in  the  DES-action. 

Clarke  defines  a  module  to  be  either  a  main  program  or  a  single  subprogram  that  has 

one  entry  and  one  exit  point  and  defines  control  flow  graph  as  follows. 

A  control  flow  graph  of  a  module  M  is  a  (not  necessarily  unique)  di¬ 
rected  graph  G(M)  =  (N,  E,  ns,  nf,  where  A  is  the  (finite)  set  of  nodes,  E  c: 

NX  N  is  the  set  of  edges,  ns  €.  N  is  called  the  start  node,  and  n^e  N  is  called 
the  final  node.  Each  node  in  N,  except  the  start  node  and  the  final  node,  rep¬ 
resents  a  statement  fragment  in  M,  where  a  statement  fragment  can  be  a  part 
of  a  statement  or  a  whole  statement.  [Clarke  et  al.  1989] 

Clarke  defines  PATH(M)  as  the  set  of  all  paths  in  G(M)  [Clarke  et  al.  1989].  Jorgen¬ 
son  refers  to  “a  program  P  that  has  a  program  graph  G(P),  and  a  set  of  program  variables 
V”  in  the  following  four  definitions  [Jorgenson  1995]. 

Node  n  €  G(P)  is  a  defining  node  of  the  variable  v  e  V,  written  as 
DEF(v,n),  iff  the  value  of  the  variable  v  is  defined  at  the  statement  fragment 
corresponding  to  node  n. 

Node  n  e  G(P)  is  a  usage  node  of  the  variable  v  €  V,  written  as 
USE(v,n),  iff  the  value  of  the  variable  v  is  used  at  the  statement  fragment 
corresponding  to  node  n. 

A  definition-use  (sub)path  with  respect  to  a  variable  v  (denoted  du- 
path)  is  a  (sub)path  in  PATHS(P)  such  that,  for  some  v  €  V,  there  are  define 
and  usage  nodes  DEF(v,m)  and  USE(v,n)  such  m  and  n  are  the  initial  and 
final  nodes  of  the  (sub)path. 

A  definition-clear  (sub)path  with  respect  to  a  variable  v  (denoted  dc- 
path)  is  a  definition-use  (sub)path  in  PATHS(P)  with  initial  and  final  nodes 
DEF(v,m)  and  USE(v,n)  such  that  no  other  node  in  the  (sub)path  is  a  defin¬ 
ing  node  of  v  [Jorgenson  1995]. 

The  discrepancy  between  the  views  of  time  in  SM-actions  and  DES-actions  reflects 
the  fact  that  the  internal  clock  is  continually  updated  by  the  hardware  in  the  target  system 
and  is  managed  by  the  EDC  policy  implementation  in  the  DES  system.  Every  du-path  with 
respect  to  the  simulation-clock  in  an  EDC  DES-action  is  a  dc-path  whose  defining  node  is 
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the  clock-update-operation  that  preceded  the  action.  Every  usage  node  with  respect  to  the 
internal  clock  in  a  SM-action  on  the  target  platform  must  be  viewed  as  though  there  were 
an  immediately  preceding  defining  node  for  the  internal  clock  in  the  program  graph. 

This  is  not  a  problem  for  the  DES-actions  in  the  hypothetical  model  depicted  in  Fig. 
2.2.  In  that  model,  the  clock  update  operation  immediately  precedes  the  single  statement  in 
the  DES-action.  However,  it  is  a  problem  for  HLL  statement-level  modelling  because  a  sin¬ 
gle  HLL  statement  can  mask  machine-code-level  branching  and  preemption  by  higher  pri¬ 
ority  tasks. 

E.  APPROACH 

This  thesis  avoids  the  problem  caused  by  HLL  statement-level  modelling  by  em¬ 
ploying  two  related  strategies.  First,  it  delegates  synchronization  and  timing  operations  to 
the  software-architecture-domain  and  imposes  policies  that  prohibit  application-domain 
access  to  HLL  statements  for  timing  and  synchronization.  This  allows  the  two  implemen¬ 
tations  of  the  software-architecture,  the  MPS  and  the  SMPS,  to  have  the  same  interface. 
Second,  it  prohibits  application-domain  access  to  the  internal  clock  and  simulation  clock, 
and  provides  access  to  logical  clocks  instead.  The  logical  clock  is  updated  to  the  value  of 
the  internal  clock  just  prior  to  SM-action  invocation,  so  every  du-path  with  respect  to  the 
internal  clock  is  a  dc-path  whose  defining  node  is  the  clock-update-operation  that  preceded 
the  action.  This  assures  that  application-domain  du-paths  with  respect  to  logical  clocks  are 
the  same  in  the  SM-actions  as  in  the  DES-actions. 
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III.  THE  MESSAGE-PASSING  SUBSYSTEMS 


The  first  section  of  this  chapter  defines  the  terminology  and  graphical  notation  used 
to  describe  the  MPS  and  SMPS.  The  second  section  describes  the  MPS  and  SMPS  from  a 
single  application-level  viewpoint.  It  also  describes  the  sufficient  conditions  to  achieve  the 
goal  of  assuring  that  the  application  code  running  with  the  MPS  exhibits  the  same  behavior 
when  running  with  the  SMPS.  The  third  section  describes  the  SMPS  model  of  MPS  oper¬ 
ation  in  detail. 

A.  TERMINOLOGY  AND  GRAPHICAL  NOTATION 

There  is  no  standard  terminology  to  distinguish  between  conceptual  entities  of  ob¬ 
ject-oriented  analysis  (OOA),  object-oriented  design  (OOD),  and  object-oriented  program¬ 
ming  (OOP).  This  thesis  follows  SMM  convention  by  using  the  term  object  to  refer  to  a  set 
of  real-world  things  at  the  analysis  level  [Shlaer  and  Mellor  1992],  Individuals  in  the  set 
are  object-instances.  Design  describes  the  approach  to  implementing  the  application  spec¬ 
ified  in  the  analysis.  This  thesis  also  employs  the  SMM  convention  of  using  the  term  class 
to  refer  to  a  set  of  entities  at  the  design  level  [Shlaer  and  Mellor  1992],  Individuals  in  the 
set  are  referred  to  as  class  instances  or  class  members.  Every  design  class  is  implemented 
in  a  corresponding  Java  class.  The  term  member-data  is  used  to  refer  to  the  data  associated 
with  a  class  member.  The  term  class-data  is  used  to  refer  to  data  that  is  global  to  all  instanc¬ 
es  of  a  class. 

A  number  of  OOA  diagrams  are  presented  in  the  appendices  to  facilitate  the  de¬ 
scriptions  of  system  structure  and  function.  These  diagrams  use  OMT  graphic  notation 
[Rumbaugh  1991]  but  use  SMM  semantics  [Shlaer  and  Mellor  1992], 
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Objects  in  the  object-information  model  (OIM)  diagrams  are  depicted  as  boxes  with 
two  compartments.  The  top  compartment  contains  the  object  name,  and  the  bottom  com¬ 
partment  contains  object  attributes.  Attributes  with  an  asterisk  are  object  identifiers.  A  sin¬ 
gle  asterisk  denotes  a  primary  identifier  and  more  than  one  asterisk  denotes  an  auxiliary 
identifier.  An  attribute  followed  by  “(R/i),”  where  n  is  some  number,  is  a  relational  attribute 
that  formalizes  a  relationship. 

Object  relationships  are  bidirectional  and  with  the  exception  of  subclass-superclass 
relationships,  are  depicted  as  connectors  with  arrowheads  on  each  end.  Clear  and  black  ar¬ 
rowheads  denote  conditional  and  unconditional  participants  in  relationships.  Multiplicity  is 
indicated  by  one  or  two  arrowheads  on  an  end  of  a  relationship  connector.  One  arrowhead 
indicates  a  single  participant  and  two  arrowheads  indicates  many  participants.  Relationship 
R7  in  Fig.  A-l  depicts  a  one-to-many  conditional  relationship  that  shows  that  each  instance 
of  Activator  may  be  associated  with  zero  or  more  instances  of  UnscheduledMessage.  It  also 
specifies  that  each  instances  of  UncheduledMessage  is  always  associated  with  an  instance 
of  Activator. 

The  subclass-superclass  relationship  is  depicted  by  a  triangle  and  a  set  of  connec¬ 
tors.  The  connectors  emanating  from  the  base  of  the  triangle  are  attached  to  the  subclasses. 
The  connector  emanating  from  the  apex  of  the  triangle  is  attached  to  the  superclass.  Rela¬ 
tionship  R5  in  Fig.  A-l  depicts  a  subclass-superclass  relationship.  The  UnscheduledMes¬ 
sage  and  ScheduledMessage  objects  are  subclasses  of  MpsMessage.  Each  of  these  inherits 
the  attributes  of  the  ScheduledMessage  superclass  object. 

In  state-model  diagrams,  boxes  with  rounded  comers  denote  states  and  arrows  de¬ 
note  transitions.  Transitions  are  labelled  with  the  event  label  and  event  data  may  be  listed 
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between  parentheses  next  to  the  label.  The  state  action  is  textually  described  in  pseudocode 
contained  in  the  state  box.  An  event  designation  preceded  by  “%g”  denotes  event  genera¬ 
tion.  Event  generation  is  equivalent  to  sending  an  event  to  the  state-model  of  the  destination 
object.  The  event  destination  can  be  inferred  from  the  event  name  and  the  pseudocode.  For 
example,  the  TH  in  the  TH4  event  in  the  “Getting  Message”  state  shown  in  Fig.  A-3  in¬ 
dicates  that  its  destination  is  the  thread  state  model. 

In  OOA,  delayed-event-delivery  is  the  delivery  of  an  event  to  an  object’s  state-mod¬ 
el  at  a  specified  time.  This  capability  is  represented  in  the  SMM  formalism  by  the  prede¬ 
fined  timer  object.  The  TIMJ.set  timer  event  has  an  event  label,  a  delivery  time,  a 
destination  object-instance,  and  a  destination  timer-instance.  This  event  causes  the  timer- 
instance  to  send  the  named  event  at  the  specified  time  to  the  object-instance.  The  non-SMM 
event,  TIM2: cancel,  denotes  delayed  event-delivery  cancellation.  TIM7:fire  denotes  timer 
expiry  for  a  SMM  timer. 

B.  APPLICATION-LEVEL  VIEW  OF  THE  MPS  AND  THE  SMPS 
1.  Overview 

The  application-binary-code  consistency  (ABCC)  requirement  is  that  the  same  ap¬ 
plication  binary-code  execute  in  both  the  target  execution-environment  and  in  the  simula¬ 
tion  model.  This  investigation  used  an  MPS-based  software  architecture  that  mapped  one 
SM-action  execution  to  one  MPS  message-activation.  In  the  SMPS,  each  SM-action  exe¬ 
cution  must  be  implemented  with  one  DES-action  for  the  SMPS  to  be  ABCC  with  the  MPS. 
This  section  describes  the  MPS  architecture  design-properties  that  contribute  to  ABCC. 

The  MPS  and  SMPS  each  comprise  a  framework  to  implement  OOA  models.  The 
frameworks  support  applications  that  depend  on  event-delivery  for  communication  and 
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state-model  execution  for  functionality.  Each  framework  provides  capabilities  to  imple¬ 
ment  the  concepts  of  active  objects,  passive  objects,  synchronous  inter-object  communica¬ 
tion,  asynchronous  communication,  and  delayed-event-delivery. 

In  the  MPS  operational  model,  state-machine-execution  threads,  called  activators, 
generate  messages  in  SM-actions  and  transfer  them  to  activator  message-buffers  or  to  the 
timer-thread  delay-queue.  The  timer-thread  transfers  messages  in  the  delay-queue  to  the 
appropriate  activator  message-buffers  at  the  scheduled  delivery  time  for  each  message.  An 
activator  repeatedly  acquires  the  next  message  from  its  buffer  and  executes  the  appropriate 
SM-action.  However,  an  activator  will  wait  for  a  message  if  none  are  available. 

The  MPS  and  SMPS  define  two  superclasses,  MpsObject  and  MpsMessage,  both 
shown  in  Fig.  A-l  and  Fig.  A-2,  that  provide  many  of  the  interfaces  needed  to  implement 
the  information  structure  and  system  dynamics  specified  in  an  OOA  model.  Application  de¬ 
velopers  produce  specializations  of  MpsObject  and  MpsMessage  that  extend  their  proper¬ 
ties  and  inherit  their  interfaces.  Specializations  of  MpsObject  contain  member-data  that 
correspond  to  object-attributes  defined  in  the  application  OIM.  Such  specializations  also 
contain  methods  that  implement  state-model  actions  for  active  objects  in  an  application 
OOA.  Direct  access  to  member-data  or  get-methods  and  ^wt-methods  implements  synchro¬ 
nous  inter-object  communication  specified  by  accessor-processes  in  state-model  ADFDs. 

The  activator-objects  (AO)  in  an  MPS-based  application  are  the  activators,  MpsOb- 
jects,  and  MpsMessages  shown  in  Fig.  A-l  and  Fig.  A-2.  Execution  priority  forms  a  parti¬ 
tion  on  the  set  of  AO  in  MPS-based  applications.  The  partition  is  indicated  by  relationship 
R1  in  Fig.  A-l  and  Fig.  A-2.  All  MpsObject  and  MpsMessage  methods  are  restricted  to  ex¬ 
ecute  in  the  context  of  the  activator  with  the  priority  that  defines  their  equivalence  class. 
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AOp,  with  two  exceptions.  The  two  exceptions  are  the  methods  that  implement  event-gen¬ 
eration  and  delayed  event-delivery.  Instances  of  each  MpsMessage  subclass  may  only  be 
sent  to  the  MpsObject  subclass,  or  to  instances  of  the  subclass  indicated  by  relationship  R4. 

Specializations  of  MpsMessage  implement  events  specified  in  OOA  state-models. 
The  MpsObject  superclass  defines  a  send-radhod  that  takes  a  parameter  of  type  Unsched- 
uledMssage  to  implement  event-generation.  UnscheduledMessage-instances  are  placed  in 
the  activator  message-buffer  depicted  in  relationship  R7.  Event  data  are  implemented  as 
MpsMessage  member-data. 

The  timer,  the  delay-queue,  the  MpsObject  schedule-method,  and  the  Sched- 
uledMessage  subclass  of  MpsMessage  provide  the  OOA  delayed-event-delivery  capabili¬ 
ty.  Relationship  R6  in  Fig.  A-l  and  Fig.  A-2  depicts  the  delay-queue  and  its  relationship  to 
the  timer.  The  schedule-method  has  two  arguments,  an  activation-time  and  an  Sched- 
uledMessage-instance.  When  a  schedule-method  is  invoked,  it  assigns  the  activation-time 
to  the  ScheduledMessage-instance  and  inserts  the  instance  into  the  delay-queue.  The  timer 
repeatedly  gets  the  ScheduledMessage-instance  with  the  earliest  activation-time,  waits  un¬ 
til  that  time  is  reached,  and  then  transfers  the  MpsMessage-instance  to  the  appropriate  ac¬ 
tivator  message-buffer. 

The  MpsMessage  class  has  an  abstract  acfr'varte-method  that  must  be  overridden 
with  a  concrete  implementation  by  each  concrete  MpsMessage  subclass.  Activate-method 
execution  must  determine  the  next  state  for  the  destination  MpsObject-instance  and  execute 
the  SM-action  on  its  behalf.  Each  activator  serially  executes  SM-actions  on  behalf  of  its 
MpsObject-instances  by  executing  activate-methods. 
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2.  Policies  and  Properties 

Clarke  defines  a  program  P  with  a  set  of  variables  V  [Clarke  et  al.  1989].  An  acti- 
vate-method  A  in  program  P  with  control  flow  graph  G(A)  =  (N,  E,  ns,  nf)  has  initial-state 
Sj  in  which  (veSj)  <=>  (ve  V  a  neN  a  USE(v,n)).  Activate-method  A  has  a  final  state,  Sf, 
in  which  (veSf)  <=>  (ve  V  a  neN  a  DEF(v,n)).  An  activate-method  that  generates  the  same 
final  state  in  the  MPS  and  SMPS  when  given  the  same  initial  state  has  activate-execution 
(AE)  predictability. 

An  SMPS  program  that  executes  its  activate-methods  in  the  same  order  in  the 
SMPS  as  in  the  MPS  has  activate-invocation-order  (AIO)  consistency.  An  MPS-based  ap¬ 
plication  will  have  the  same  timing  and  synchronization  properties  and  will  produce  the 
same  results  in  the  SMPS  as  in  the  MPS  if  the  activate-methods  are  AE-predictable  and  the 
SMPS  program  is  AlO-consistent. 

Let  V  be  the  set  of  variables  v  in  program  P  and  let  denote  the  happens  before 
relation  [Lamport  1978]  applied  to  the  execution-order  of  statements  and  statement  frag¬ 
ments  in  P.  An  MPS-based  program  P  will  have  AE-predictability  if  for  all  of  P’s  execu¬ 
tions  and  for  any  two  non-unique  activate-methods  X  and  Y  in  P  with  G(X)  =  (M,  G,  ms, 
mf)  and  G(Y)  =  (L,  F,  ls,  If),  DEF(v,l)  and  USE(v,m)  =>  (m^lj  a  lf-»ms)  v  (If— »ms  a 
mf-»ls). 

The  MPS  and  SMPS  data-access  policy  is  that  for  any  two  MpsObject-instances, 
01pe  AOp  and  02q€  AOq,  p=q  =>  synchronous  data  exchange  is  allowed,  p*q  =s>  synchro¬ 
nous  data  exchange  is  not  allowed  and  must  be  performed  by  message  passing.  The  serial 
nature  of  activator  state-machine  execution  and  the  data-access  policy  assure  that  each 
MpsMessage-instance  in  AOp  will  have  exclusive  access  to  all  of  the  member-data  in  AOp 
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for  the  duration  of  its  activate-method.  The  data-access  policy  confers  AE-predictability  on 
MPS-based  applications. 

An  activate-method  that  accesses  the  system  clock  will  violate  the  data-access  pol¬ 
icy  and  may  undermine  AE-predictability  because  the  value  of  the  system  clock  will 
change  independently  of  activate-method  execution.  This  problem  is  avoided  by  assigning 
an  EventClock- instance  to  each  activator.  The  EventClock-instance  is  updated  to  system¬ 
time  just  prior  to  each  activate-method  execution  and  remains  fixed  for  its  duration.  This  is 
depicted  by  relationships  R9  in  Fig.  A-l  and  Fig.  A-2.  The  MpsObject  class  defines  a  mil- 
//s-method  that  returns  the  time  of  the  associated  EventClock-instance  via  relationships  R2 
and  R9. 

The  MPS  and  SMPS  have  a  synchronization  policy  with  two  rules.  First,  the  OOA 
state-models  for  an  application  must  represent  all  synchronization  requirements.  Second, 
all  required  synchronization  must  be  implemented  by  message-passing.  This  policy  prohib¬ 
its  application-level  use  of  HLL  statements  for  timing  and  synchronization.  That  would 
cause  variation  in  execution-time  that  would  not  be  modelled  in  the  SMPS.  An  activate- 
method  has  path  execution-time  (PET)  consistency  if  the  variation  in  its  MPS  execution¬ 
time  only  results  from  preemption  by  another  MPS  thread  or  from  executing  different  sub¬ 
paths  in  G(A).  PET-consistent  activate-method  execution-time  depends  only  on  its  initial 
state,  the  platform  performance,  and  its  preemption  time. 

The  SMPS  model  assumes  PET-consistency.  The  potential  AlO-consistency  of  an 
SMPS  model  of  an  AE-predictable  and  PET-consistent  MPS-application  depends  on  the  fi¬ 
delity  of  underlying  run-time  system  model,  the  MPS-overhead  model,  and  the  activate- 
method  execution-time  model.  Model  inaccuracy  will  degrade  AlO-consistency. 
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MpsMessage  send-times  in  the  MPS  and  SMPS  will  be  different  if  messages  are  al¬ 
lowed  to  be  sent  at  any  arbitrary  time  during  activate-method  execution.  The  time  that  an 
MpsMessage-instance  is  sent  affects  the  time  that  its  activate-method  is  invoked.  An  SMPS 
application  cannot  be  AlO-consistent  if  message  send-times  are  different  in  the  MPS  and 
SMPS.  As  can  be  seen  in  Fig.  3.1,  this  results  from  the  different  views  of  time  presented  by 
the  MPS  system  clock  and  the  SMPS  EDC. 

SMPS  and  MPS  message  send-times  must  be  constrained  to  occur  at  the  SM-action 
end-time.  This  requirement  is  very  cumbersome  for  programmers.  In  order  to  avoid  this, 
the  sercd-method  and  schedule- method  only  place  messages  in  temporary  storage.  The  ac¬ 
tivator  transfers  the  messages  from  temporary  storage  to  the  appropriate  buffers  upon  re¬ 
turning  from  the  activate-method.  The  SMPS  will  have  accounted  for  activate-method  cpu- 
time  consumption  and  preemption-time  by  that  point.  The  message  transfer  takes  place  in 
the  Transferring  Msgs  action  of  the  activator  state-model  shown  in  Fig.  A-4. 

An  SMPS  version  of  an  MPS-based  application  can  have  the  same  timing  and  syn¬ 
chronization  properties  and  can  generate  the  same  results  if  the  activate-methods  have  AE- 
predictability  and  the  SMPS  version  has  AlO-consistency.  An  application  that  complies 
with  the  data-access  and  synchronization  policies  will  have  AE-predictable  activate-meth¬ 
ods.  An  application  must  have  PET-consi stent  activate-methods  and  PET-consistent  MPS- 
infrastructure  code  to  be  AlO-consistent.  However,  an  SMPS-application  must  incorporate 
an  adequate  platform-performance  model  into  all  activate-methods  and  into  the  SMPS  in¬ 
frastructure  to  be  AlO-consistent. 
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c. 


THE  SMPS  MODEL  OF  THE  MPS 


In  the  MPS  operational  model,  MpsMessage-instances  are  generated  in  MpsObject 
SM-actions  and  are  either  transferred  to  activator  message-buffers  or  to  the  delay-queue. 
The  timer  transfers  messages  in  the  delay-queue  to  the  appropriate  activator  message-buff¬ 
ers  at  the  message  activation-times.  Activators  acquire  messages  from  their  message-buff¬ 
ers  and  invoke  their  activate-methods. 

The  SMPS  must  also  account  for  preemption  in  the  MPS  to  support  AlO-consisten- 
cy.  The  model  of  the  Java  run-time  executive  (RTE)  is  depicted  in  the  interactions  between 
the  RTE  state-model  shown  in  Fig.  A-5  and  the  thread  state-model  shown  in  Fig.  A-6.  The 
model  of  the  implementation  of  the  activator-thread  raw-method  is  depicted  in  the  interac¬ 
tions  between  the  activator  state-model  shown  in  Fig.  A-5  and  the  thread  state-model 
shown  in  Fig.  A-6.  The  model  of  the  implementation  of  the  timer-thread  run-method  is  de¬ 
picted  in  the  interactions  between  the  timer  state-model  shown  in  Fig.  A-3  and  the  thread 
state-model  shown  in  Fig.  A-6.  The  next  three  subsections  describe  the  SMPS  model  of  the 
Java  implementations  of  the  MPS  activator  and  timer. 

1.  Thread  Context  Switching 

The  MPS  activator  and  the  MPS  timer  behavioral  models  are  split  into  a  generic 
thread  state-model  and  a  role-specific  state-model.  The  thread  state-model  implements  the 
model  of  context  switching.  Dynamic  priorities  are  used  to  prevent  preemption  during  cer¬ 
tain  portions  of  the  life-cycles  of  activators  and  timers.  This  reduces  the  number  of  states 
in  which  context  switching  can  occur. 

Context  switching  is  modelled  in  the  thread  state-model  as  a  three-state  transition 
from  Ready  to  Switching  Context  to  Running  as  shown  in  Fig.  A-6.  When  the  RTE  sends 
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TH2  to  a  thread  in  the  Ready  state,  the  thread  moves  to  the  Switching  Context  state.  When 
the  thread  arrives  in  that  state,  it  schedules  another  TH2  event  to  be  delivered  to  itself  when 
the  context  switching  time  expires.  The  TH2  transition  from  Switching  Context  to  Running 
invokes  an  SM  action  to  send  TH2  to  its  client  thread  subclass  state-model.  Context  switch¬ 
es  in  the  timer  and  activator  classes  are  denoted  by  the  TH2  transition  in  Fig.  A-3  and  Fig. 
A-4. 

2.  The  Activator 

In  order  to  achieve  AlOconsistent,  the  SMPS  model  must  account  for  CPU-time 
consumed  by  activate-method  execution,  activator-preemption,  MPS  overhead,  and  thread 
context-switching. 

The  synchronized  modifier  is  used  to  implement  mutual  exclusion  in  Java.  Each 
Java  class-instance  has  a  lock  [Gosling  et  al.  1 996] .  A  thread  that  invokes  an  instance’ s  syn¬ 
chronized  method  implicitly  requests  the  instance’s  lock.  If  the  lock  is  owned  by  another 


Figure  3.1.  Java  Wait-Notify  Interaction 
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thread,  the  requesting  thread  is  blocked  until  the  lock  becomes  available  to  it.  The  MPS 
uses  synchronized  methods  to  synchronize  MpsMessage-acquisition  and  transfer. 

The  wait  and  notify  methods  are  used  to  implement  condition  synchronization  in 
Java.  A  thread  that  calls  a  instance’s  wait-method  will  block  and  be  added  to  the  instance’s 
wait-set  until  another  thread  invokes  the  instance’s  notify-method  [Gosling  et  al.  1996]. 
Notify  will  select  one  of  the  waiting  threads,  remove  it  from  the  wait-set,  and  make  it  ready 
to  run.  The  selected  thread  will  throw  InterruptedException  when  it  runs  again. 

The  sample  code  in  Fig.  3.1  depicts  a  basic  Java  wait-notify  interaction  in  a  buffer 
implementation.  A  consumer-thread  that  calls  the  geMnethod  shown  in  Fig.  3.1  will  block 
at  the  wait  statement  if  the  list  is  empty.  The  list  will  be  non-empty  after  a  producer-thread 
calls  put.  The  put-operation  calls  notify,  causing  InterruptedException  to  be  thrown  to  one 
of  the  consumer-threads  waiting  for  the  buffer’s  lock.  The  interrupted  consumer  will  exit 
the  catch  clause  after  the  producer-thread  releases  the  lock.  The  consumer-thread  will  make 
a  transition  from  the  ready  state  to  the  running  state. 

a.  Activator  Creation  and  Start-up 

Role-specific  behavior  is  acquired  by  a  thread  by  overriding  the  thread’s 
predefined  r««-method.  A  thread’s  run-method  may  execute  only  after  its  starrMnethod  has 
been  invoked. 

An  SMPS  activator-instance  is  created  in  the  Created  state  when  a  thread 
invokes  the  activator’s  constructor.  Figures  A-4  and  3 .2  show  the  TH1  -transition  from  Cre¬ 
ated  to  Starting  and  Fig.  A-4  shows  the  SM-action  for  the  Starting  state.  In  Starting,  the 
activator  sends  TH1  to  the  activator-thread’s  state-model  causing  a  transition  to  the  Ready 
state.  The  RTE  makes  the  thread  the  currently  running  thread  by  sending  TH2  to  its  state- 
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model.  This  simulates  Java  start-method  execution  and  causes  the  transition  from  the  Start¬ 
ing  state  to  the  Getting  Message  state  shown  in  Fig.  3.2  and  Fig.  A-4. 

The  SMPS  model  of  an  MPS  activator  primarily  models  its  run-method.  The 
activator  run-method  repeatedly  acquires  a  message  from  its  message-buffer,  updates  its 
EventClock-instance,  executes  the  message  activate-method,  and  transfers  the  generated 
messages  from  temporary  storage  to  their  target  buffers.  Figure  3.3  shows  an  abridged  ver¬ 
sion  of  the  source  code  for  the  MPS  activator  run-method. 
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State-Event  Chart  for  Message  Acquisition  with  an 
Initially  Non-Empty  Message-Buffer 
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b.  Non-Blocking  Message-Acquisition 

Line  four  in  Fig.  3.3  shows  an  example  of  MpsMessage-acquisition.  Figure 
3.2  depicts  MpsMessage-acquisition  in  a  scenario  with  an  initially  non-empty  message- 
buffer.  An  MPS  activator  that  invokes  get  for  a  non-empty  message-buffer  will  not  block. 
This  is  modelled  by  the  else  branch  in  the  Getting  Message  action  shown  in  Fig.  A-4. 

An  SMPS  activator  must  compute  the  CPU-time  consumed  by  the  Event- 
Clock  update  operation  and  the  operation  that  removes  the  message  at  the  front  of  its  mes¬ 
sage-buffer.  It  must  also  schedule  itself  to  complete  its  message-acquisition  after  that 
amount  of  time  has  elapsed.  This  is  shown  by  the  transition  labelled  TH3  that  goes  from  the 
Getting  Message  state  to  the  Activate  state  shown  in  Fig.  A-4. 

Message-acquisition  CPU-time  consumption  is  simulated  by  sending  TIM1 
to  an  SMM  timer-instance.  Timer  expiry  is  represented  by  the  second  occurrence  of  TIM7 
in  Fig.  3.5.  The  timer  sends  TH3  to  the  activator  when  the  correct  amount  of  CPU-time 
elapses. 

Priority  inversion  is  the  condition  in  which  a  higher  priority  thread  is 


1 

public  void  run ( )  { 

2 

setPriority (MPS .MAX 

PRIORITY) ; 

3 

do  { 

4 

MpsMessage  msg  = 

tbuff [id] .get  ( ) ; 

5 

if  (msg  ==  null) 

1 

6 

break; 

7 

} 

8 

eclock. update ( )  ; 

9 

setPriority (pri)  ; 

10 

msg . activate ( ) ; 

11 

setPriority (MPS. MAX  PRIORITY); 

12 

transfer ( ) ; 

13 

}  while  (forever) ; 

14 

} 

Figure  3.3.  MPS  Activator  Run-Method 
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blocked  by  a  lower  priority  thread.  Consider  a  Java  program  with  three  threads  T1 ,  T2,  and 
T3  listed  in  ascending  priority.  Assume  that  they  use  the  buffer  in  Fig.  3.1  and  that  it  is  in¬ 
itially  non-empty.  The  following  sequence  of  events  will  cause  priority  inversion  because 
T1  will  be  blocked  by  T2’s  execution. 

•  T1  invokes  buffer.get  and  acquires  the  lock 

•  T2  and  T3  become  ready  to  run  when  T1  is  at  line  seven  in  Fig.  3.1 

•  T3  preempts  T1 

•  T3  invokes  buffer. put,  requests  the  lock,  and  is  added  to  buffer’s  wait 
set 

•  T2  runs 

Activators  raise  their  priority  to  the  maximum  in  the  Starting  state  or  the 
Transferring  Msgs  state  to  prevent  preemption  during  message-acquisition  and  transfer. 
This  also  avoids  activator-buffer  and  delay-queue  lock-contention  and  precludes  the  neces¬ 
sity  to  model  lock-contention  in  the  SMPS.  It  also  avoids  blocking-delay  due  to  priority  in¬ 
version. 

c.  Blocking  and  Unblocking  in  Message-acquisition 

Figure  3.4  depicts  a  scenario  with  two  activators,  A1  and  A2.  The  scenario 
begins  at  the  point  in  which  A2  begins  to  execute  the  SM-action  of  the  Getting  Message 
state.  The  empty  message-buffer  condition  will  cause  A2  to  execute  the  //-branch  in  the 
Getting  Message  SM-action  shown  in  Fig.  A-4  and  to  send  TH4  to  itself.  TH4  will  cause  it 
to  transition  to  the  Waiting  for  Message  state  depicted  in  Fig.  3.4  and  Fig.  A-4.  The  self- 
directed  TH4  event  simulates  the  effect  of  executing  a  wait-method  such  as  the  one  depict¬ 
ed  on  line  seven  of  Fig.  3.1. 
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The  following  sequence  of  events  models  the  process  by  which  an  activator 


may  become  blocked  at  a  wait  statement  like  the  one  depicted  at  line  eight  in  Fig.  3.1.  In 
the  Waiting  for  Message  SM-action,  A2  sends  TH4  to  its  thread  state-model,  causing  the 


thread  to  enter  the  Blocked  state.  In  the  Blocked  SM-action,  the  thread  sends  TH3  to  A2  and 


Activatorl  Thread  1  Activator2  Thread2  RTE  SM  Timer 


Figure  3.4. 

State-Event  Chart  for  Message  Acquisition  with  an  Initially  Empty 

Message-Buffer 
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sends  RTE3  to  the  RTE.  RTE3  causes  the  RTE  to  enter  the  Blocking  state  and  it  may  exe¬ 
cute  a  context  switch. 


After  A2  has  become  blocked,  A1  sends  TH1  to  A2’s  thread  from  the  Trans¬ 
ferring  Msgs  SM-action.  This  models  the  effect  of  invoking  notify  in  a  put  operation  as 
shown  at  line  16  of  Fig.  3.1.  TH1  causes  A2’s  thread  to  transition  from  Blocked  to  Ready 
and  to  send  TH1  to  A2,  which  is  ignored.  When  the  RTE  moves  A2’s  thread  from  Ready 
to  Running,  the  thread  sends  TH2  to  A2,  causing  it  to  go  from  Waiting  for  Message  to  Get¬ 
ting  Message.  A2  continues  from  that  point  as  described  in  the  discussion  for  non-blocking 
message-acquisition. 

d.  Activate-Method  Execution  and  Preemption 

Line  eight  in  Fig.  3.3  depicts  an  activator  that  acquires  a  message  and  up¬ 
dates  its  EventClock-instance  to  the  current  system  time.  The  activator  reduces  its  priority 
after  it  updates  the  EventClock  and  then  invokes  its  activate-method.  The  activate-method 
will  only  modify  the  values  of  attributes  in  the  same  AOp  and  it  may  place  generated-events 
in  temporary  storage.  However,  no  simulation-time  will  elapse  during  activate-method  ex¬ 
ecution  in  the  SMPS. 

Activate-methods  must  be  invoked  at  the  same  time  in  the  SMPS  as  they 
would  have  been  in  the  MPS  in  order  to  be  AlO-consistent.  Activate-method  completion¬ 
time  is  the  time  at  which  an  activate-method  completes  in  the  MPS.  The  SMPS  models  this 
as  the  sum  of  activate-method  start-time  plus  the  CPU-time  consumed  by  the  activate- 
method  plus  its  preemption-time  plus  the  context-switching  time  associated  with  preemp¬ 
tion. 
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The  activator  must  delay  the  occurrence  of  two  operations  until  activate- 
method  completion-time  to  achieve  AlO-consistency.  First,  it  must  delay  the  transfer  of  the 
messages  from  temporary  storage  to  message-buffers.  Second,  it  must  delay  the  start  of  the 
next  activate-method. 

The  activator-class  defines  an  add2A ctionTime-method  that  adds  an  incre¬ 
ment  of  simulation-time  to  the  value  of  an  internal  action-time  variable.  In  the  SMPS,  this 
variable’s  value  is  reset  prior  to  each  activate-method  invocation. 

The  activate-method  uses  add2ActionTime  to  dynamically  accumulate  acti¬ 
vate-method  timing  information  during  execution.  The  action-time  variable  should  contain 
the  amount  of  CPU-time  that  would  be  consumed  during  MPS-based  activate-method  ex¬ 
ecution  in  the  target  environment.  Action-time  is  unused  in  the  MPS.  However;  it  is  used 
by  the  SMPS  to  compute  activate-method  completion-time. 

An  activator  executes  the  activate-method  in  the  SM-action  of  the  Activate 
state  shown  in  Fig.  A-4.  The  activator  transitions  to  Activating  after  completing  the  acti¬ 
vate-method.  The  transitions  between  Activating  and  Preempted  simulate  the  passage  of 
activate-method  execution-time  and  preemption-time. 

Preemption  can  only  occur  in  the  MPS  during  activate-method  execution 
because  message-acquisition  and  message-transfer  are  performed  at  elevated  priorities. 
Preemption  only  occurs  when  a  timer’s  timeout  expires  and  the  timer  transfers  a  message 
to  an  activator-buffer  owned  by  a  waiting  activator.  The  message-transfer  unblocks  the 
waiting  activator  as  described  in  the  discussion  on  blocking  message-acquisition.  The  acti¬ 
vator  will  also  continue  processing  until  it  reaches  the  Activating  state.  At  this  point,  the 
activator  will  have  executed  its  activate-method  without  affecting  any  objects  in  other 
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AOpS  due  to  AE-predictability  constraints.  If  the  activator  lowers  it  priority  to  a  lower  pri¬ 
ority  than  the  preempted  activator’s  priority,  the  RTE  will  perform  a  context-switch  and  re¬ 
store  the  preempted  activator  to  the  running  state. 

The  amount  of  time  elapsed  during  preemption  will  be  equal  to  the  sum  of 
the  timer  message-transfer  time  and  the  activator  message-acquisition  time.  Although  its 
activate-method  will  have  executed,  activate-method  execution-time  does  not  affect  the 
simulation  clock  at  that  point. 

The  state-event  chart  shown  in  Fig.  3.5  shows  the  sequence  of  events  and 
state  transitions  involved  in  preempting  activator  A1  in  the  Activating  state.  Initially,  the 
SMPS  timer  will  have  scheduled  an  event-delivery  by  setting  the  SMM  timer  to  expire  at  a 
later  time.  This  timer  expiry  is  depicted  by  the  appearance  of  TIM7  in  the  upper  part  of  the 
SMM  timeline  in  Fig.  3.5.  The  SMM  timer  sends  TH1  to  the  SMPS  timer-thread  when  the 
SMM  timer  expires.  The  SMPS  timer-thread  interrupts  the  SMPS  timer  and  the  SMPS  tim¬ 
er  proceeds  through  a  succession  of  state  transitions  causing  it  to  send  RTE1  to  the  RTE. 
The  RTE  compares  Al’s  priority  and  the  timer’s  priority  and  sends  TH1  to  the  A 1 -thread 
and  TH2  to  timer-thread  because  the  timer-thread  has  a  higher  priority  than  Al.  The  Al- 
thread  transitions  to  the  Ready  state  and  sends  TH1  to  Al.  Al  transitions  to  the  Preempted 
state  when  it  receives  TH1. 

The  simulation  clock  is  updated  twice  during  this  series  of  interactions. 
First,  it  is  updated  at  the  time  of  timer  expiry  depicted  by  the  appearance  of  TIM7  in  the 
upper  part  of  the  SMM  timeline  shown  in  Fig.  3.5.  It  is  updated  again  at  the  second  appear¬ 
ance  of  TIM7  that  represents  the  context-switching  time  of  the  timer-thread  when  it  transi¬ 
tions  from  CtxT oRunningl  to  Getting  Message.  Al  computes  Tremain,  the  amount  of 
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activate-method  execution  time  remaining,  by  subtracting  its  last  activation  start-time  from 
the  current  simulation-time.  When  the  RTE  causes  it  to  transition  to  the  Activating  state 
again,  it  will  recompute  its  activate-method  completion-time  as  the  sum  of  the  then-current 
simulation-time  plus  Tremain. 
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Figure  3.5.  State-Event  Chart  for  Preemption 
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3. 


The  Timer 


Activators  remove  the  message  from  the  buffer  in  the  Getting  Message  state  and 
transfer  messages  from  the  buffer  in  the  Transfer  Msg  state.  However,  the  timer  does  not 
remove  the  message  from  the  delay-queue  until  it  reaches  the  Transfer  Msg  state  because 
a  message  with  an  earlier  transfer  time  can  be  inserted  into  the  delay  queue  while  the  timer 
is  in  the  Timeout  state.  The  timer  is  never  preempted  because  it  always  executes  at  the 
thread  message-transfer  and  message-acquisition  priority. 

The  delay-queue  maintains  a  list  of  ScheduledMessage-instances  that  are  sorted  by 
activation-time.  Figure  A-3  shows  that  the  timer  transitions  to  the  Timeout  state  when  it 
identifies  the  message  at  the  front  of  the  delay-queue.  In  the  Timeout  SM-action,  the  timer 
sends  TH3  to  its  thread  and  schedules  TH1  to  be  sent  to  its  thread  after  the  timeout  period 
elapses.  These  events  cause  the  timer-thread  to  transition  immediately  to  Blocked  and  later 
to  Ready  when  the  timeout  elapses.  Figure  3.5  shows  that  the  SMM  timer  sends  TH1  to  the 
SMPS  timer-thread.  That  causes  the  SMPS  timer-thread  to  transition  to  the  Ready  state. 
The  timer-thread  sends  TH1  to  the  timer,  which  is  ignored. 

The  delay-queue  put-method  compares  the  activation-time  of  the  new  MpsMessage 
argument  against  the  timer’s  current-message  activation-time.  If  the  new  message  activa¬ 
tion-time  is  earlier,  then  it  pushes  the  current-message  and  the  new  message  argument  onto 
the  delay-queue.  It  then  sets  the  current-message  to  null  and  sends  TH1  to  the  timer’s 
thread.  This  causes  the  timer  to  process  the  earlier  message. 

D.  SUMMARY 

The  application-binary-code  consistency  (ABCC)  requirement  is  that  the  same  ap¬ 
plication  binary-code  execute  in  both  the  target  execution-environment  and  in  the  simula- 
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tion  model.  The  investigation  used  two  implementations  of  a  message-passing  architecture, 
the  MPS  and  the  SMPS,  that  implement  state-machine-execution  engines  to  support  appli¬ 
cation-binary-code  consistency  (ABCC). 

Several  MPS  design-properties  contribute  to  ABCC.  First,  each  SM-action  execu¬ 
tion  was  implemented  with  a  single  message-activation.  In  the  SMPS,  each  SM-action  ex¬ 
ecution  was  implemented  with  one  DES-action.  Second,  the  MPS  and  SMPS  message- 
activation  methods  must  generate  the  same  final  state,  given  the  same  initial  state.  Third, 
an  MPS-based  program  must  execute  its  SM-action  methods  at  the  same  time  in  the  SMPS 
as  in  the  MPS.  Finally,  data  access  and  synchronization  policies  must  assure  mutually  ex¬ 
clusive  data  access. 

An  MPS-based  application  can  be  ABCC  for  an  MPS  and  SMPS  that  have  these  de¬ 
sign  properties  if  the  variations  in  its  sub-path  execution-times  only  results  from  preemp¬ 
tion  by  another  MPS  thread.  The  SMPS  sub-path  execution  times  are  obtained  from  an 
MPS  platform  performance  model  (MPPM).  However,  if  execution  conditions  are  impos¬ 
sible  to  specify  and  control,  then  the  MPPM  will  be  invalid  and  ABCC  cannot  be  achieved. 
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IV.  MPS  PLATFORM  PERFORMANCE  MODELLING 


The  first  section  of  this  chapter  discusses  MPS  platform  performance  model 
(MPPM)  requirements  for  validity.  The  second  section  provides  an  overview  of  dual-loop 
(DL)  testing,  and  describes  DL  test  structure  principles,  design  considerations,  and  side  ef¬ 
fects  in  DL  testing.  The  third  section  describes  MPPM  development  in  the  investigation 
used  in  this  thesis.  The  fourth  section  describes  how  the  MPPM  was  incorporated  into  the 
SMPS.  The  fifth  section  provides  conclusions  on  MPS  platform  performance  modelling. 

A.  MPPM  REQUIREMENTS 

The  validity  of  the  SMPS  and  its  associated  MPS-based  application  depends  par¬ 
tially  on  the  fidelity  of  the  MPPM.  An  MPS  platform  performance  model  (MPPM)  is  a  set 
of  functions  that  return  MPS  execution-time  estimates  (ETE)  that  model  the  execution- 
times  of  MPS  module  sub-paths  under  MPS-application  execution  conditions.  A  Java  com¬ 
pilation  configuration  comprises  the  Java  compiler  and  the  compiler  options  used  to  com¬ 
pile  the  MPS  and  MPS-applications.  An  MPS  execution  platform  consists  of  a  Java  virtual 
machine  (JVM),  an  operating  system,  and  a  hardware  platform.  MPS-application  execution 
conditions  are  defined  by  a  Java  compilation  configuration,  an  MPS  execution  platform 
configuration,  and  a  system  loading  specification  for  a  particular  MPS-application  execu¬ 
tion. 

An  SMPS  execution  has  strict  MPPM-validity  if  the  MPPM  functions  return  MPS 
ETEs  that  are  the  same  as  the  corresponding  MPS  sub-path  execution-times  at  the  same 
time  relative  to  the  program  execution  start  time.  This  definition  does  not  require  or  assume 
PET-consistency.  An  SMPS  execution  that  has  strict  MPPM-validity  is  AlO-consistent 
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with  an  MPS  program  execution  and  can  be  used  to  reproduce  MPS  application  behavior 
in  a  run-time  environment  that  is  free  of  the  probe  effect. 

The  MPS  execution  platform  used  for  the  investigation  presented  in  this  thesis  was 
a  200  MHz  Pentium  PRO  computer  with  a  256  KB  on-chip  cache  and  96  MB  of  60  ns  RAM 
running  under  Windows  NT  4.0  and  the  Java  Development  Kit  (JDK)  version  1.1.6.  If  MPS 
execution  conditions  are  impossible  to  specify  and  control  for  such  a  configuration  then  a 
strictly  valid  MPPM  cannot  be  developed.  In  addition,  MPS  applications  executing  on  an 
unpredictable  platform  are  not  PET-consistent.  This  raises  the  question  of  whether  an 
MPPM  can  be  developed  that  is  sufficiently  predictable  to  support  useful  software  testing 
in  contrast  to  providing  strictly  reproducible  behavior.  An  MPPM  is  useful  if  the  sum  of  the 
effort  devoted  to  its  development  and  to  testing  a  set  of  control-flow  paths  in  the  SMPS  is 
less  than  the  effort  required  to  test  the  same  paths  in  the  MPS.  MPPM  usefulness  is  related 
to  the  difficulty  of  testing  the  real  system. 

A  partial  MPPM  was  developed  for  this  configuration  that  consists  primarily  of 
Java  language  feature  ETEs.  This  MPPM  contains  of  a  set  of  mappings  of  feature-names  to 
ETEs  and  does  not  account  for  performance  variations  due  to  system  loading  or  properties 
of  the  execution  platform. 

B.  DUAL-LOOP  (DL)  TESTING  OVERVIEW 

1.  DL  Test  Structure 

The  DL  approach  is  based  on  the  assumption  (i.e.,  the  DL-assumption)  that  the  dif¬ 
ference  in  execution-times  of  two  segments  of  code  that  are  identical  except  for  the  pres¬ 
ence  of  a  feature-of-interest  is  equal  to  the  execution-time  of  the  feature-of-interest.  A  dual¬ 
loop  test  generates  an  ETE  of  a  feature-of-interest  by  comparing  the  execution-times  of  an 
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experimental  loop  and  a  control  loop.  The  two  loops  are  identical  except  that  the  experi¬ 
mental  loop  contains  the  feature-of-interest.  For  control  loop  execution-time,  Tc,  and  ex¬ 
perimental  loop  execution-time,  Te,  the  feature-of-interest  execution-time,  Ty,  is  computed 
as  Ty-  Te  -  Tc  [Pollack  and  Campbell,  1990]. 

Let  Mef  and  Mct  be  the  measured  execution-times  of  Alterations  of  the  experimental 
loop  and  N  iterations  of  the  control  loop.  Let  My  be  the  measured  feature  execution-time 
computed  as  My-  (Met  -  Mcj)l N.  The  basic  clock  resolution  of  the  clock-function,  x,  is  usu¬ 
ally  too  coarse  to  permit  Mei  and  Mcj  to  be  used  as  estimates  of  Te  and  Tc  when  N- 1 .  The 
time  measurement  uncertainty  is  x  for  Met  and  for  Mcy  so  NMy-  2x  <  NTy<  NMy+  2x.  The 
value  of  JV  required  to  confine  the  measurement  uncertainty  to  a  fraction,  p,  of  NMy  is  given 
by  N>  2V(pMy)  [Pollack  and  Campbell,  1990]. 

Altman  examined  the  DL-assumption  after  measuring  negative  ETEs  for  some  DL 
benchmarks  written  in  Ada  [Altman,  1987].  He  attributed  some  of  the  main  sources  of  dis¬ 
tortion  in  test  results  as  being  due  to  design  or  implementation  errors  and  interference  from 
side-effects.  Design  and  implementation  errors  can  be  addressed.  However  side-effects  are 
due  to  external  factors  that  can  be  impractical  or  impossible  to  precisely  quantify  and  con¬ 
trol. 

2.  DL  Test  Design  Considerations 

An  in-depth  knowledge  of  the  target  programming  language  may  be  required  to 
avoid  DL  test  design  errors  and  to  avoid  compromising  MPPM  fidelity.  An  MPS  applica¬ 
tion  that  uses  many  language  features  that  differ  in  subtle  ways  can  necessitate  a  large  test 
suite  to  generate  an  MPPM  for  an  MPS  application.  For  example,  consider  the  problem  of 
measuring  Java  calling  overhead  for  methods  with  various  numbers  of  arguments  and  var- 
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ious  argument  types.  A  conservative  assumption  is  that  any  different  signature  type  has  po¬ 
tentially  different  performance  implications. 

Table  1  shows  an  example  of  variability  in  Java  method  signature  types  based  on 
the  conservative  assumption.  The  top  row  contains  the  variability  category  for  each  col¬ 
umn.  The  last  row  contains  the  number  of  values  for  each  category.  The  intermediate  rows 
display  the  names  of  the  values  in  the  category  or  an  indication  of  the  presence  or  absence 
of  a  value  in  the  category.  Some  of  the  factors  pertain  to  the  value  or  presence  of  a  throws 
clause,  a  synchronized  modifier,  a  static  modifier,  access  modifier,  or  a  final  modifier.  The 
others  pertain  to  the  method  return  type  and  the  argument  types. 

The  number  of  unordered  combinations  of  argument  types  that  can  be  constructed 
from  three  arguments  and  seven  argument  types  is  (k+n-\)\l(n-\)\k\  where  n  is  one  more 
than  the  number  of  data  types  and  k  is  the  number  of  arguments.  This  is  analogous  to  de¬ 
termining  the  number  of  different  colorings  of  k  golf  balls  with  n  colors  [Anderson,  1974], 
The  extra  argument  corresponds  to  the  void  argument  or  the  absence  of  an  argument.  The 
number  of  different  unordered  combinations  is  120  (i.e.,  (8+3-1)!  /  (8-l)!*3!).  The  number 
of  different  signatures  is  30720.  This  value  is  the  product  of  the  number  of  factors  in  each 
category  multiplied  by  the  number  of  different  combinations  of  arguments  (i.e., 
2*2*2*2*4*8*120). 

Not  every  kind  of  method  signature  variation  affects  performance.  Some  of  the  Java 
method  modifiers  probably  only  affect  compile-time  consistency  checks.  Table  2  shows  an 
optimistic  interpretation  of  variability  in  Java  method  signature  types.  The  categories  in  ta¬ 
ble  2  are  partially  based  on  properties  in  generated  code  that  are  assumed  to  affect  perform¬ 
ance.  For  example,  methods  that  have  the  static,  final,  or  private  modifiers  or  that  are 
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declared  in  a  class  that  has  the  final  or  private  modifiers  may  be  able  to  be  inlined.  The  table 
also  assumes  that  argument  size  rather  than  argument  type  is  relevant  to  method-calling 
overhead  execution-time. 


throws 

synch. 

mod. 

static 

mod. 

final 

mod. 

access 

mod. 

return 

type 

argument 

type 

present 

present 

present 

present 

public 

char 

absent 

absent 

absent 

absent 

pro¬ 

tected 

mmi 

boolean 

private 

boolean 

int 

absent 

mm 

long 

float 

double 

double 

“refer¬ 

ence” 

refer¬ 

ence 

absent 

2 

2 

2 

2 

4 

8 

7 

Table  4.1 :  Conservative  Interpretation  of  Variability  in  Java  Method  Signature  Types 


The  number  of  argument  signature  types  that  can  be  constructed  from  three  argu¬ 
ments  and  four  data  types  is  35  (i.e.,  (5+3-1)!  /  (5-l)!*3!).  The  number  of  different  signa¬ 
ture  types  based  on  the  optimistic  assumption  is  140. 


synch,  mod. 

inline-able 

argument 
size  (bytes) 

present 

true 

1 

absent 

false 

2 

4 

2 

2 

4 

Table  4.2:  Optimistic  Interpretation  of  Variability  in  Java  Method  Signature  Types 
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synch,  mod. 

inline-able 

argument 
size  (bytes) 

8 

2 

2 

4 

Table  4.2:  Optimistic  Interpretation  of  Variability  in  Java  Method  Signature  Types 

3.  Side  Effects 

The  MPS  compilation  and  execution  environment  contains  several  possible  sources 
of  instability  for  MPS  sub-path  execution-time.  These  sources  of  instability  can  be  attrib¬ 
uted  to  the  JDK  1.1.6  JVM,  Windows  NT  4.0,  or  the  Pentium  PRO  hardware  platform.  The 
JDK  1.1.6  JVM  contains  a  bytecode  interpreter  and  a  Just-in-time  (JIT)  compiler.  The  JIT 
performs  adaptive  optimization  at  run-time  by  determining  the  methods  that  are  called  most 
often  and  by  generating  machine  code  for  them  on-the-fly  [Yellin,  1996],  This  can  lead  to 
variations  in  sub-path  execution-times  in  the  absence  of  other  factors.  The  JVM  also  per¬ 
forms  garbage  collection  at  unpredictable  times. 

Windows  NT  4.0  is  a  preemptive  multi-tasking  operating  system  that  performs  var¬ 
ious  operating  system  services  in  independent  execution  threads.  These  can  preempt  an 
MPS  application  and  result  in  variations  in  sub-path  execution-time.  The  Pentium  PRO 
processor  has  a  high-speed  memory  cache.  Variations  in  the  sequence  of  memory  fetches 
can  affect  the  percentage  of  cache  hits  and  lead  to  a  differences  in  sub-path  execution- 
times. 

C.  MPPM  DEVELOPMENT 

1.  The  MPPM  of  the  Passage  of  Time 

It  is  essential  to  obtain  an  estimate  of  x,  Tcr,  because  x  is  integral  to  the  application- 
level  view  of  the  passage  of  time.  At  any  time,  T,  the  value  returned  by  the  Java  clock  func- 
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tion,  system.  currentTimeMillis,  will  be  LL(77c)Jt_|,  where  i _ I  is  the  floor  function.  The  value 

of  x  is  also  required  to  compute  the  number  of  iterations  to  execute  the  control  and  experi¬ 
mental  loops  that  are  used  measure  the  execution-time  of  a  particular  code  segment.  The 
value  returned  from  system.currentTimeMillis  was  assigned  to  each  element  of  a  large  ar¬ 
ray.  The  sample  values  consisting  of  the  non-zero  differences  between  successive  array  el¬ 
ements  were  counted  and  summed  to  obtain  Tcr.  This  process  was  repeated  ten  times  and 
the  average  of  the  samples,  Tcr,  was  computed  to  be  approximately  15.625  milliseconds 
(ms).  The  source  code  for  the  test  program  is  shown  in  Fig.  B-l. 

Each  MPS  and  SMPS  activator  updates  its  event-clock  with  the  current  value  of  the 
SystemClock  at  the  beginning  of  each  action  as  shown  in  Fig.  A-3  and  Fig.  A-4.  The  Sys- 
temClock  function  was  implemented  in  the  MPS  by  calling  the  Java  System.current¬ 
TimeMillis  method  from  the  MpsRealClock.millis  method.  In  the  SMPS,  the 
MpsRealClock.millis  method  models  the  Java  System.currentTimeMillis  method.  This  pro¬ 
vides  a  more  accurate  application-level  view  of  current-time  than  simply  returning  the  val¬ 
ue  of  the  EDC-clock.  The  SMPS  MpsRealClock.millis  source  code  is  shown  in  Fig.  B-2. 

Figure  B-3  shows  the  source  code  for  the  test  to  determine  the  Java  wait-method  res¬ 
olution.  The  test  performed  30  invocations  of  the  wnY-method  for  each  value  in  the  range 
of  one  to  50  milliseconds.  Figure  4. 1  shows  the  results  of  the  test.  Requested  delay  is  shown 
on  the  abscissa  and  measured  delay  is  shown  on  the  ordinate.  In  each  case,  the  measured 
delay  resolution  is  Tcr,  but  the  average  measured  delay  is  close  to  the  requested  value.  The 
results  do  not  validate  a  particular  model  of  wazY-method  resolution.  However,  they  do  not 
contradict  the  optimistic  assumption  that  vrazY-method  resolution  is  high  relative  to  the 
clock  function  resolution.The  SMPS  timer  implementation  design  is  based  on  the  optimis- 
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Requested  Delay  (ms) 


Figure  4.1 .  Java  Wait  Statement  Resolution  for  a  200  MHz  Pentium  Pro  with 
96  MB  60  ns  DRAM  and  256K  On-Chip  Cache 

tic  assumption  and  uses  the  EDC-clock  rather  than  the  SMPS  MpsRealClock  to  compute 
delay-times  for  delayed-event-delivery.  However,  the  application-view  of  delayed-event- 
delivery  duration  can  only  be  accessed  using  MpsRealClock.millis  so  its  view  of  the  clock 
function  resolution  is  still  Tcr. 


D.  GENERAL  DL  TEST  DESIGN  AND  IMPLEMENTATION 

The  majority  of  the  DL  tests  were  implemented  as  type  extensions  of  the  abstract 
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FeatureTest  class.  FeatureTest  declares  the  following  four  abstract  methods:  initialize ,  cal¬ 
ibrate,  and  execute.  Each  concrete  subclass  must  implement  those  three  methods.  Initialize 
initializes  the  test  state.  Calibrate  executes  multiple  iterations  of  a  loop  that  exercises  the 
control  and  experimental  loops  N  times  per  iteration,  and  doubles  N  for  each  successive  it¬ 
eration.  It  calculates  7^ for  a  feature  and  completes  when  Ty>  (2T CIyp,  where p= QM.  Exe¬ 
cute  re-computes  7^-at  the  calibrated  value  for  N,  M  times,  where  M,  is  the  number  of  test 
repetitions.  Initially,  Mwas  set  at  29,  so  a  total  of  30  repetitions  of  each  test  was  performed. 
However,  Mwas  eventually  reset  to  zero  because  there  was  so  little  variation  between  suc¬ 
cessive  runs. 

Figure  4.2  shows  the  test  results  and  output  of  a  method  calling  overhead  test,  pro¬ 
gram  smsipubv3pMf.  Program  smsipubv3pMf  measures  the  calling-overhead  of  a  method 
with  the  public,  static,  and  synchronized  modifiers.  The  method  also  has  three  integer  ar¬ 
guments  and  no  return  value.  Figure  4.2  shows  that  N  ranged  from  2 16  to  221  during  the 
calibration  portion  of  the  test.  The  variation  in  Mf  was  less  than  0.4%  of  the  mean  for  the 
five  runs  and  the  average  value  for  Mf  was  approximately  2.12  microseconds. 

E.  INCORPORATING  THE  MPPM  INTO  THE  SMPS 

The  CpuCharger  interface  requires  an  implementation  to  provide  methods  that  add 
a  quantity  of  time  to  an  accumulator,  clear  an  accumulator,  and  return  the  accumulated  val¬ 
ue.  The  SMPS  activator  and  timer  implement  the  CpuCharger  interface  and  use  CpuCha¬ 
rger  methods  to  maintain  a  record  of  estimated  CPU-time  use.  The  activator  defines 
an  add2ActionTime- method  that  adds  an  increment  of  simulation-time  to  the  value  of  an 
internal  action-time  variable.  This  is  exported  to  MPS-applications  and  provides  a  way  for 
MPS  applications  to  communicate  activate-method  CPU-time  consumption  to  activators. 
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The  ETEs  obtained  from  the  DL  tests  were  stored  as  a  set  of  mappings  of  DL  test- 
names  to  ETEs.  Java  statements  and  ETE  names  were  embedded  in  special  comments  in 
the  SMPS  source  code.  Figure  B-4  shows  the  SMPS  MpsFifo. append  method  with  embed¬ 
ded  Java  statements  and  ETE-names.  The  source  was  submitted  to  a  processor  that  strips 
out  the  special  comments  and  replaces  the  ETE-names  with  their  values.  Figure  B-5  shows 
the  result  of  processing  MpsFifo. append. 

Figure  B-5  shows  that  Vappend_l mf  contains  the  sum  of  the  ETEs  for  the  append- 
method  calling  overhead,  the  {/^statement  evaluation,  and  the  statements  in  the  first  branch 
of  the  //-statement.  Vappend_2mf contains  the  sum  of  the  ETEs  for  the  append-meihod  call¬ 
ing  overhead,  the  /^statement  evaluation,  and  the  statements  in  the  second  branch  of  the  if- 
statement.  Each  branch  invokes  cc.  charge  which  adds  the  DD-path  ETE  to  the  CPU-time 


-  Feature  Time  Estimates  - 

executing  method .  sms'ipubv3pMf  test 
N : 65536,  Tf:141,  Te:172,  Tc:31 
N : 131072,  Tf:297,  Te:344,  Tc:47 
N: 262144,  Tf:563,  Te:672,  Tc:109 
N : 524288 ,  Tf:1124,  Te:1359,  Tc:235 
N : 1048576,  Tf:2235,  Te:2688,  Tc:453 
N : 2097152,  Tf:4453,  Te:5359,  Tc:906 
method. smsipubv3pMf 

Series  0,  Number  of  tests  5,  N:  2097152, 
p:  0.01,  units:  ms 
+ 


Test,  Te, 

Tc, 

Tf,  Mf 

1/ 

5359, 

906, 

4453, 

0.0021233558654785156 

2, 

5328, 

891, 

4437, 

0.0021157264709472656 

3, 

5328, 

891, 

4437, 

0.0021157264709472656 

4, 

5328, 

890, 

4438, 

0.0021162033081054688 

5, 

-1- 

5344, 

891, 

4453, 

0.0021233558654785156 

Mean:  5337.4, 

893.8, 

4443.6,  0.0021188735961914064 

-  registered  - 


Figure  4.2.  Output  from  the  smsipubv3pMf'Dudi[-\ooip  Test 
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accumulator  for  the  SMPS  thread. 


Language  features  such  as  conditional  evaluation  and  self-modifying  expressions 
should  be  avoided  unless  the  DD-path  execution  can  be  known  ahead  of  time,  since  they 
contain  more  than  one  DD-path  in  a  single  statement. 

F.  CONCLUSIONS 

A  partial  MPPM  was  developed  for  the  target  platform  using  the  dual-loop  ap¬ 
proach  to  measuring  execution-time.  The  validity  of  an  MPPM  developed  using  the  DL  test 
approach  on  a  predictable  platform  is  related  to  the  validity  of  the  DL  assumption.  A  large 
number  of  DL  tests  may  be  required  to  accurately  reflect  DD-path  execution-times  due  to 
programming  language  subtleties.  Good  DL  test  design  requires  an  in-depth  knowledge  of 
the  target  programming  language. 

Factors  such  as  the  JDK  1.1.6  just-in-time  compiler,  the  Windows  NT  4.0  preemp¬ 
tive  multi-tasking  operating  system,  and  the  Pentium  PRO  high-speed  cache  are  sources  of 
unpredictably  in  the  MPS  execution  platform.  If  MPS  execution  platform  performance  is 
unpredictable  then  MPS-application  behavior  cannot  be  precisely  reproduced  using  the 
SMPS.  However,  an  MPPM  can  be  useful  if  its  reduces  the  effort  to  test  control-paths  that 
are  difficult  to  reproduce  in  real  systems. 
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V.  DEMONSTRATION  PROGRAMS 


This  chapter  is  concerned  with  demonstrating  and  evaluating  the  synchronization 
and  timing  properties  of  MPS-based  applications  running  with  the  SMPS.  Two  MPS-based 
programs  were  developed  that  illustrate  well-understood  synchronization  and  timing  prin¬ 
ciples.  The  first  is  an  MPS-based  solution  to  the  “Dining  Philosophers”  problem  [Dijkstra, 
1971]  that  was  developed  to  study  SMPS  timing  and  synchronization.  The  second  is  an 
MPS-based  program  with  Rate  Monotonic  Scheduling  (RMS)  priority  assignments  and  ar¬ 
tificial  workloads  [Sha  and  Goodenough,  1990].  This  program  was  developed  to  study 
SMPS  timing  and  the  model  of  a  preemptive  multi-threaded  run-time  system. 

The  first  section  describes  the  “Dining  Philosophers”  problem  and  the  MPS-based 
solution  implemented  with  the  uniprocessor-based  SMPS.  It  also  compares  timing  and  syn¬ 
chronization  in  the  actual  program  to  timing  and  synchronization  in  the  ideal  case.  The  sec¬ 
ond  section  describes  the  RMS  program  and  compares  timing  and  preemption  in  the  actual 
program  to  timing  and  preemption  in  the  ideal  case.  The  third  section  presents  the  conclu¬ 
sions  and  describes  the  implications  for  the  distributed  systems  question. 

A.  DINING  PHILOSOPHERS  (DP) 

In  this  problem,  five  philosophers  are  seated  at  a  round  table.  Each  philosopher  has 
a  plate,  and  between  each  pair  of  plates  is  a  chopstick.  A  philosopher  must  acquire  the  chop¬ 
sticks  to  the  immediate  left  and  right  before  he  can  eat.  This  prevents  adjacent  philosophers 
from  eating  at  the  same  time.  Each  philosopher  repeats  a  cycle  of  acquiring  chopsticks,  eat¬ 
ing,  relinquishing  chopsticks,  and  then  thinking,  until  no  more  rice  remains.  If  each  philos¬ 
opher  initially  picks  up  the  chopstick  on  the  left  before  any  philosopher  has  a  chance  to  pick 
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up  the  one  on  the  right,  deadlock  will  occur.  Deadlock  will  not  occur  if  a  server  assures  that 
no  more  than  N-l  philosophers  are  allowed  to  eat  at  a  time  [Bums  and  Wellings,  1995]. 

The  test  scenario  used  a  time-scale  measured  in  milliseconds  to  allow  target  plat¬ 
form  overhead  effects  to  be  expressed  in  the  actual  DP-program  execution.  DP  eating  and 
thinking  activity-durations  were  chosen  so  that  the  ideal  case  would  exhibit  both  concurrent 
and  non-concurrent  eating  periods  over  a  relatively  small  time  period. 

The  initial  condition  for  the  test  scenario  consisted  of  five  philosophers  and  ten 
available  bites  of  rice.  Each  eating-period  duration  for  the  philosophers  Plato,  Hegel  and 
Descartes,  was  150  milliseconds  (ms)  and  their  thinking-period  duration  was  250  ms.  The 
eating-period  duration  for  Lao  Tsu  and  Socrates  was  250  ms  and  their  thinking-period  du¬ 
ration  was  500  ms.  Figure  5-1  shows  the  physical  arrangement  of  the  plates  and  chopsticks 
for  the  five  philosophers  seated  at  the  table.  The  OOA  models  shown  in  Fig.  C-l  through 


Figure  5.1.  Physical  Arrangement  of  Dining 
Philosophers 
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Fig.  C-6  specify  the  solution  implemented  in  the  MPS-based  DP  test  application.  The  ar¬ 
rows  in  Fig.  5-1  represent  relationships  R1  and  R2  in  the  DP  object  information  model 
(OIM)  shown  in  Fig.  C- 1 .  The  arrows  emanate  from  the  seating  position  for  the  philosopher 
that  owns  the  referential  attributes  for  the  designated  relationship.  Relationship  R1  denotes 
the  philosopher  seated  to  the  right  of  the  philosopher  that  owns  the  referential  attribute  that 
formalizes  relationship  R1 .  Relationship  R2  denotes  the  chopstick  to  the  left  of  the  philos¬ 
opher  that  owns  the  referential  attribute  that  formalizes  relationship  R2. 

The  ideal  case  was  defined  as  hypothetical  DP-program  execution  on  a  platform 
with  a  perfect  system  clock  an  no  execution  overhead.  The  ideal  case  is  shown  in  Fig.  5-2. 
Thinking  and  eating  activities  are  indicated  for  each  philosopher  by  relatively  lower  and 
higher  line  segment  height.  The  ten  line  segments  with  the  highest  of  the  three  heights  iden¬ 
tify  the  times  that  the  rice  was  consumed.  Plato  and  Descartes  eat  simultaneously  between 
1350  ms  and  1400  ms  and  Plato  and  Lao  Tsu  eat  simultaneously  between  1400  ms  and  1500 


Figure  5.2.  Dining  Philosophers:  Ideal  Case 
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ms.  Figure  5-1  shows  that  Plato  is  not  adjacent  to  Lao  Tsu  or  Descartes. 


No  satisfactory  estimate  of  context-switch  time  was  obtained  during  the  investiga¬ 
tion  presented  in  this  thesis.  Context-switch  time  was  measured  as  the  time  taken  for  a 
number  of  threads,  N,  that  were  blocked  at  a  wait  statement  to  run.  This  approach  was  not 
perfected.  Available  memory  also  limited  N  to  1200,  and  N  was  not  large  enough  to  meet 
the  accuracy  criterion  of  N  >  2i Z(pMj)  for  p= 0. 1 .  Nevertheless,  the  context-switch  time  es¬ 
timate  of  0.7  ms  was  incorporated  into  the  MPPM  to  demonstrate  SMPS  functionality. 

The  other  feature-time  estimates  (FTE)  are  relatively  precise  under  the  DL  assump¬ 
tion.  The  number  of  control  loop  and  experimental  loop  iterations,  N,  ranged  from  219  to 
227.  The  measurement  error  for  NMf  was  ±2t,  so  the  accuracy  of  Mf  was  computed  as  2x1 
N.  This  yielded  accuracies  that  ranged  from  ±3x1 0-7  ms  to  ±6x10-5  ms  for  FTEs  that  were 
obtained  with  the  standard  DL  approach.  This  demonstrates  the  potential  to  acquire  FTEs 


Elapsed  Time  (ms) 


Figure  5.3.  Dining  Philosophers:  SMPS  Execution 
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that  are  relatively  accurate  under  the  DL  assumption. 

The  actual  SMPS  DP-program  execution  used  the  partial  MPPM  described  in  chap¬ 
ter  four.  Figure  5-3  shows  that  the  eating  and  thinking  order  is  the  same  in  both  the  SMPS 
DP-program  and  the  ideal  case.  However,  there  are  relatively  small  differences  in  timing 
between  the  two.  These  differences  are  due  to  differences  in  the  models  of  system  time  and 
the  contribution  of  the  MPPM  to  SMPS  timing.  In  the  ideal  case,  no  time  elapses  during 
Plato’s  transition  from  Created  to  Wait  shown  in  Fig.  C-2.  However,  1.4017  ms  elapses 
during  the  same  transition  in  the  SMPS  DP-program.  This  is  shown  in  section  D.l  of  Ap¬ 
pendix  D,  which  contains  the  application-level  program-traces  for  the  SMPS  DP-program. 
Lines  two  through  seven  in  section  D.l  indicate  that  1 .4017  ms  is  consumed  by  Plato’s  tran¬ 
sition  from  Created  to  Wait.  Section  D.2  shows  the  SMPS-level  program  traces  that  corre¬ 
spond  to  lines  six  and  seven  in  section  D.l  This  shows  three  components  to  the  transition 
time.  The  first  is  the  0.7  ms  start-up  context-switch  time  for  the  timer  thread  indicated  on 
lines  14-15.  The  second  is  the  0.7  ms  start-up  context-switch  time  for  the  activator  thread 
shown  on  lines  23-25.  The  third  is  the  activator’s  0.0017  ms  message  acquisition-time  for 
the  initial  PI  event  for  the  transition  from  Created  to  Wait  that  is  indicated  on  lines  23-25. 

In  the  ideal  case,  Hegel  begins  to  eat  a  bite  of  rice  during  150-300  ms.  However, 
line  59  in  section  D.l  shows  that  at  152.9148  ms,  Hegel  schedules  eating  to  complete  at 
T=290  ms.  The  actual  completion  time  is  shown  on  line  62  to  be  at  T=29 1.4098  ms.  The 
difference  between  the  ideal  and  actual  start  times  of  T=150  ms  and  T=152.9148  ms  is  due 
to  the  SMPS  model  of  MPS  overhead.  However,  the  difference  between  the  ideal  300  ms 
completion  time  and  the  scheduled  290  ms  completion  time  is  due  to  the  model  of  the  ap¬ 
plication-level  view  of  system-clock  resolution.  At  any  time,  T,  the  value  returned  to  the 
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application  by  the  simulated  system-clock  function  would  be  LL(77t)Jt_|.  When  7=  1 52.9 1 48 
and  t=15.625,  the  value  returned  from  the  simulated  system-clock  function  is  140.  When 
the  150  ms  eating-time  duration  is  added,  the  290  ms  time  correctly  reflects  what  the  com¬ 
pletion  time  should  be  based  on  the  MPPM  used  in  the  SMPS  DP  demonstration. 

B.  PERIODIC  HARMONIC  TASK  SET  WITH  RMS  PRIORITY  ASSIGN¬ 
MENT 

This  MPS-based  RMS  program  was  developed  to  study  SMPS  timing  and  the  mod¬ 
el  of  a  preemptive  multi-threaded  run-time  system.  The  program  modelled  three  independ¬ 
ent  periodic  tasks:  TO,  Tl,  and  T2.  Each  task  had  a  workload  and  a  period  in  which  to 
complete  its  work.  The  ideal  RMS  scenario  was  based  on  the  assumption  that  there  was  a 
perfect  system  clock,  no  system  overhead,  and  no  MPS  overhead. 

The  workloads  (wl)  chosen  for  the  experiment  were  20, 40,  and  80  milliseconds  and 
task  periods  ipd)  were  62,  124,  and  248  milliseconds,  respectively.  Priority  assignments 
were  inversely  related  to  task  period,  in  accordance  with  RMS  principles.  These  conditions 
were  designed  for  high  CPU  utilization  so  that  the  addition  of  MPS  overhead  in  the  SMPS 
version  might  cause  a  task  to  fail  to  complete  its  workload  by  the  end  of  its  period. 

All  three  tasks  were  started  at  the  same  time  and  timing  data  were  gathered  until  the 
end  of  lowest  priority  task’s  first  period.  The  RMS  critical  zone  theorem  states:  “For  a  set 
of  independent  periodic  tasks,  if  each  task  meets  its  first  deadline  when  all  tasks  are  started 
at  the  same  time,  then  the  deadlines  will  always  be  met  for  any  combination  of  start  times” 
[Sha  and  Goodenough,  1990]. 

In  the  SMPS  version,  activators  A0,  Al,  and  A2  provided  the  execution  context  for 
the  three  tasks  the  tasks  TO,  Tl,  and  T2.  Task  behavior  was  modelled  with  a  specialization 
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of  MpsObject  and  a  specialization  of  MpsMessage.  The  MpsObject  specialization  had 
work  and  wait  methods.  Work  modelled  task  workload  execution  by  executing  the  MpsOb¬ 
ject  addToActionTime  method.  Wait  modelled  delay  by  scheduling  the  MpsMessage  in¬ 
stance  to  be  delivered  at  the  end  of  the  period. 

Figure  5-4  shows  the  task  execution  patterns  for  the  ideal  case.  TO  executed  its 
workload  four  times,  consuming  80  ms  of  CPU  time.  T1  executed  its  workload  two  times, 
also  consuming  80  ms  of  CPU  time.  T2  executed  its  workload  once,  also  consuming  80  ms 
of  CPU  time.  T2  completed  its  workload  at  time  T=240  ms,  close  to  the  end  of  its  period  at 
T=248  ms.  T2  started  executing  its  workload  at  T=60  ms,  but  was  preempted  by  TO  at  T=62 
ms  and  T=186  ms. 

Figure  5-5  shows  the  task  execution  patterns  for  the  SMPS  version.  The  SMPS  ver¬ 
sion  has  three  activator  threads  and  the  timer  thread.  The  activators  execute  at  their  activate 
priority  (P4),  or  else  at  maximum  priority  (P= 4).  They  operate  at  maximum  priority  when¬ 
ever  they  perform  any  processing  other  than  activate  method  processing.  Figure  A-4  shows 
the  points  in  the  state  model  at  which  the  activators  raise  and  lower  priority.  The  two  line 
segment  levels  in  each  activator  plot  in  Fig.  5-5  denote  activate-method  processing  and 
higher  priority  processing.  The  timer  thread  always  operates  at  the  maximum  priority.  The 
spikes  in  the  timer  plot  denote  points  at  which  the  timer  either  gets  a  message  or  transfers 
a  message  to  an  activator  buffer.  T1  was  not  preempted  in  the  ideal  case  because  the  sum 
of  the  workloads  for  TO  and  T1  was  less  than  Tl’s  period.  However,  there  is  overhead  due 
to  four  context  switches  and  message  handling  before  time  T=60  ms  in  the  SMPS  version. 
The  four  context  switches  consume  2.8  ms  of  CPU  time,  in  accordance  with  the  MPPM. 
This  is  enough  CPU  time  to  assure  that  T1  does  not  complete  its  workload  within  TO’s  pe- 
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riod.  This  is  depicted  by  the  spike  at  T=85.3  ms  in  Al’s  plot  and  represents  the  small 
amount  of  CPU  time  remaining  for  A1  to  complete  T1  ’s  workload.  Section  D.3  provides 
detailed  program  traces  for  the  preemption  activity  that  takes  place  during  the  interval  from 
T=62  ms  to  T=63.4  ms.  Context  switching  and  message  handling  consume  enough  CPU¬ 
time  to  prevent  T2  from  completing  its  workload  before  the  end  of  its  period.  T2  executes 
73. 1 6  ms  of  its  workload  by  the  end  of  its  period  at  T=248,  with  6.84  ms  remaining. 

C.  SUMMARY 

An  MPS-based  solution  to  the  “Dining  Philosophers”  (DP)  and  an  MPS-based  pro¬ 
gram  with  Rate  Monotonic  Scheduling  (RMS)  priority  assignments  were  developed  to  test 
the  uniprocessor  SMPS  timing,  synchronization,  and  the  model  of  preemption.  The  actual 
behavior  was  compared  to  ideal  behavior  of  the  DP  and  RMS  programs.  The  SMPS  DP  pro¬ 
gram  had  the  same  ordering  of  eating,  thinking  and  waiting  activities  as  the  ideal  case  and 
appeared  to  have  the  same  synchronization  properties  as  the  ideal  case.  Small  differences 
between  ideal  DP  timing  and  actual  SMPS  DP  timing  were  observed.  However,  the  ob- 
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Figure  5.4.  Ideal  Task  Execution  Patterns  for  Three  Tasks  with 
RMS  Priority  Assignments 
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served  differences  in  timing  were  found  to  correctly  reflect  the  MPPM. 

The  RMS  program  was  designed  to  exhibit  high  CPU  utilization.  The  ideal  case  had 
eight  ms  of  unused  CPU-time  in  the  lowest  priority  task’s  first  period.  In  the  SMPS  version, 
the  lowest  priority  task  failed  to  complete  its  workload  within  its  period.  This  result  cor¬ 
rectly  reflected  the  effect  of  MPS  overhead  for  the  MPPM  used  in  the  experiment. 

The  results  of  the  demonstrations  indicate  that  it  is  feasible  to  develop  a  discrete- 
event  simulation  (DES)  implementation  of  a  software  architecture  that  has  application  bi- 
nary-code  consistency  (ABCC)  with  an  implementation  designed  for  a  uniprocessor-based 
target  execution-environment.  The  distributed-systems  question  adds  another  dimension  to 
the  uniprocessor  question,  but  does  not  add  new  research  questions.  There  are  two  prob¬ 
lems  in  the  distributed-systems  question.  The  first  is  how  to  model  a  multiprocessor-based 
single-platform  system.  The  approach  developed  in  this  investigation  can  address  that 
problem  as  a  variation  of  the  same  software  architecture.  Figure  A-7  shows  an  object  infor- 
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mation  model  (OIM)  for  a  simulation  model  of  a  simulated  multiprocessor-based  MPS.  Re¬ 
lationship  R17  shown  in  Fig.  A-7  indicates  the  possibility  of  multiple  processors  under  the 
control  of  a  single  run-time  executive.  Relationship  R16  denotes  the  relationship  between 
threads  in  the  running  state  and  the  associated  CPU.  No  modifications  to  the  thread  state 
models  shown  in  Fig.  A-6  would  be  required  to  accommodate  a  multiprocessor-based  mod¬ 
el.  The  RTE  state  model  would  be  the  only  state  model  affected  by  the  new  requirement. 
Figure  A-8  shows  the  state  model  for  a  multiprocessor-based  RTE.  The  difference  between 
the  SMPS  RTE  state  model  shown  in  Fig.  A-5  and  the  SDMPS  RTE  state  model  shown  in 
Fig.  A-8  is  that  the  SDMPS  RTE  assigns  eligible  threads  to  processors. 

The  second  problem  in  the  distributed-systems  question  is  how  to  model  multiple 
communicating  platforms.  This  would  require  modelling  the  communication  system  as  a 
separate  architectural  domain.  Simulation  models  of  communication  networks  are  often 
used  to  assist  in  making  design  decisions  and  to  do  protocol  testing.  Network  simulation 
techniques  could  be  used  to  develop  a  simulation  model  of  the  communication  system  do¬ 
main.  Figure  A-9  shows  a  domain  model  for  a  simulated  MPS-based  distributed  applica¬ 
tion. 

Multiple  MPPMs  would  also  have  to  be  accessible  to  the  simulation  model  of  a  het¬ 
erogeneous  distributed  system.  SDMPS  sub-paths  could  contain  function  calls  that  accept¬ 
ed  an  MPPM  parameter  to  obtain  ETEs  for  the  correct  platform  rather  than  have  hard-coded 
MPPM  ETEs  in  the  SDMPS. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  investigation  presented  in  this  thesis  was  concerned  with  two  questions  related 
to  avoiding  the  probe  effect  in  testing  real-time  software  implemented  in  high-level  lan¬ 
guages  (HLL)  developed  using  Object-Oriented  Analysis  (OOA).  The  uniprocessor  ques¬ 
tion  is  whether  it  is  feasible  to  develop  a  simulation  model  of  an  application-independent 
software-architecture  and  environment  in  which  to  execute  the  same  HLL  application-level 
binary  code  as  would  execute  in  a  uniprocesor-based  execution-environment.  The  distrib¬ 
uted-systems  question  is  whether  it  is  feasible  to  extend  the  approach  to  distributed  real¬ 
time  applications. 

The  first  section  of  this  chapter  summarizes  the  investigation  and  states  the  conclu¬ 
sions.  The  second  section  discusses  the  implications  of  this  research  for  related  subject  ar¬ 
eas  and  makes  recommendations  for  further  research. 

A.  SUMMARY  AND  CONCLUSIONS 

Implementations  of  the  same  software  architecture  (SA)  that  generate  the  same  pro¬ 
gram  results  with  the  same  application-level  binary-code  have  application-binary-code 
consistency  (ABCC).  This  investigation  employed  a  message-passing  subsystem  (MPS) 
software-architecture  and  a  discrete-event  simulation  (DES)  model  of  the  MPS  (SMPS)  to 
investigate  the  uniprocessor  question.  An  SMPS  that  has  ABCC  with  the  MPS  supports  ap¬ 
plication-level  software  testing  conducted  under  controllable  conditions  free  of  the  probe 
effect. 

The  study  used  the  MPS  to  implement  a  set  of  state-machine  execution-engines  that 
execute  OOA  state-model  actions  (SMA).  It  restricted  application-level  SMAs  to  using  the 
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MPS  interface  for  all  timing  and  synchronization  operations.  The  approach  also  imposed  a 
data-access  policy  and  a  synchronization-policy  that  assured  mutually  exclusive  access  to 
relevant  data  by  each  active  object  for  the  duration  of  its  SMA. 

The  MPS  design  resolved  the  conflicting  views  of  time  between  a  real  application 
and  a  DES-application.  The  MPS  design  restricted  the  SMA  view  of  time  to  that  provided 
by  a  logical  clock  that  was  only  updated  to  “actual  time”  at  the  beginning  of  each  SMA  ex¬ 
ecution.  SMA  event-transmission  was  postponed  until  SMA  completion  in  both  the  MPS 
and  the  SMPS.  These  two  design  properties  supported  ABCC  by  precluding  the  necessity 
to  factor  SMA  application-code  into  multiple  DES  events  for  the  SMPS. 

The  SMPS  used  an  MPS  platform-performance  model  (MPPM).  The  MPPM  con¬ 
tained  a  model  of  the  system  clock  function  resolution  for  the  target  platform.  All  SMPS 
functions  that  accessed  the  system  clock  function  relied  on  this  model  of  clock  resolution. 
The  MPPM  also  contained  a  set  of  functions  that  returned  MPS  execution-time  estimates 
(ETE)  that  model  the  execution-times  of  MPS  module  sub-paths  under  MPS-application 
execution  conditions  in  a  target  environment.  The  study  used  a  dual-loop  (DL)  approach  to 
acquire  the  MPPM  ETEs  for  the  target  execution-environment.  The  SMPS  sub-paths  con¬ 
tained  hard-coded  MPPM  ETEs  that  were  accumulated  on-the-fly  to  obtain  SMPS  opera¬ 
tion  execution-time  estimates.  The  SMPS  used  the  ETEs  to  schedule  the  completion  of 
SMPS  SAs  as  DES  events. 

The  investigation  developed  two  MPS-based  applications  to  investigate  SMPS  tim¬ 
ing,  synchronization,  and  the  SMPS  model  of  a  preemptive  multi-threaded  run-time  sys¬ 
tem.  The  applications  had  well-understood  synchronization  and  timing  properties.  Each 
demonstration  program  ideal  case  was  defined  as  hypothetical  program  execution  on  a  plat- 
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form  with  a  perfect  system  clock  and  no  execution  overhead.  The  SMPS-based  implemen¬ 
tation  of  a  uniprocessor  model  exhibited  the  desired  behavior  during  the  observation 
periods  by  only  deviating  from  the  ideal  case  by  the  amount  expected  for  the  MPPM. 

The  results  of  the  investigation  indicated  that  it  is  feasible  to  develop  a  DES  imple¬ 
mentation  of  a  SA  that  has  ABCC  with  an  implementation  designed  for  a  uniprocessor  ex¬ 
ecution-environment.  However,  several  conditions  must  be  met.  First,  program  sub-path 
execution-times  must  be  predictable  in  the  target  environment.  Second,  the  program  sub¬ 
path  execution  times  of  the  real  implementation  must  be  available  as  a  platform-perform¬ 
ance-model  to  be  incorporated  into  the  simulation  model.  Finally,  given  a  valid  platform- 
performance-model,  it  must  be  possible  to  duplicate  the  timing  properties  of  the  real  pro¬ 
gram  in  a  simulation  model. 

The  distributed-systems  question  did  not  add  new  research  questions,  so  no  separate 
investigation  was  conducted.  There  are  two  problems  in  the  distributed-systems  question. 
The  first  is  how  to  model  a  multiprocessor-based  single-platform  system.  The  second  is 
how  to  model  multiple  heterogeneous  communicating  platforms.  The  techniques  devel¬ 
oped  in  this  investigation  for  the  uniprocessor  case  could  be  extended  to  address  the  first 
problem.  Network  simulation  techniques  could  be  used  to  address  the  second  problem. 

The  research  reported  in  this  thesis  examined  feature  timing  using  an  empirical  ap¬ 
proach.  A  need  for  realistic  timing  motivated  this  approach,  but  any  empirical  approach  is 
limited  by  the  conditions  under  which  the  study  is  conducted.  This  approach  is  expected  to 
scale  well  to  larger  subsets  of  the  Java  language,  and  may  apply  readily  to  other  languages, 
but  this  has  not  yet  been  proven.  The  results  reported  in  this  thesis  offer  a  direction  of  in¬ 
quiry,  not  a  conclusive  argument  for  applicability  to  any  specific  project. 
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B.  RECOMMENDATIONS 


The  approach  developed  in  this  investigation  allows  the  same  HLL  application-lev- 
el  binary-code  to  execute  in  both  a  target  execution-environment  and  in  a  simulation  model. 
This  property  enables  software  test  designers  to  disregard  the  intrusive  effects  of  source 
code  instrumentation  in  application-level  software  testing.  However,  the  benefit  of  this  ap¬ 
proach  is  not  necessarily  limited  to  testing  application-level  software.  It  extends  to  any 
service-domain  that  uses  the  modelled  domain  and  can  also  be  used  for  service-domain  and 
application  integration  testing. 

The  approach  will  also  add  value  to  OOA-based  software  development  environ¬ 
ments  that  automatically  generate  source  code  from  OOA  models.  The  SMM  BridgePoint 
toolset  from  Project  Technology1  uses  an  application-instance-to-architecture-instance 
mapping  and  a  system-construction  engine  to  generate  applications  from  OOA  models 
[Shlaer  and  Mellor  1997].  BridgePoint  contains  a  model  verifier  that  executes  the  state 
models  in  an  OOA  model  before  code  generation.  The  approach  developed  in  this  investi¬ 
gation  allows  designers  to  test  the  correctness  of  their  application-instance-to-architecture- 
instance  mappings  in  an  environment  free  of  the  probe  effect  by  executing  the  generated 
code  in  a  simulation  model. 

This  approach  is  also  useful  in  distributed  systems  and  network-protocol  software 
development.  Network-protocol  error-recovery  software  makes  frequent  use  of  timeouts  to 
detect  message-delivery  failures.  Higher  performance  protocols  have  tighter  timing  con¬ 
straints  and  are  often  very  time-sensitive.  Network-protocol  design  often  involves  develop¬ 
ing  a  separate  simulation  model  using  network  simulation  tools  such  as  OPNET2  or  ns3. 

1.  Project  Technology,  Inc.  7400  N.  Oracle  Rd.  Suite  365  Tucson,  AZ  85704,  http://www.pro- 
jtech.com 
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However,  the  approach  presented  in  this  thesis  can  be  used  to  run  the  actual  protocol  and 
application  code  in  the  simulation  model.  This  avoids  questions  about  differences  between 
the  protocol  software  and  the  protocol  simulation  and  only  requires  a  single  protocol  im¬ 
plementation. 

This  investigation  employed  an  SA-based  approach  that  is  essentially  language-in- 
dependent.  However,  language-specific  SA-independent  approaches  are  also  worth  consid¬ 
ering  [Huang  et  al.  1983],  This  may  be  achieved  in  Java  by  developing  a  Java  class-file 
compiler  that  replaces  the  Thread-related  bytecodes  in  class-files  with  simulated  Thread 
bytecodes.  This  approach  would  require  developing  a  bytecode-level  MPPM  and  instru¬ 
menting  the  class-files  with  CPU-time  accumulation  operations  as  part  of  class-file 
compilation.  This  approach  would  be  widely  applicable  to  Java  programs.  It  would  also  re¬ 
quire  no  source-code  level  modifications  and  has  the  advantage  that  only  a  single  DL  test- 
suite  would  need  to  be  developed  for  the  set  of  Java  byte-codes.  However,  additional  work 
would  be  needed  to  extend  the  approach  to  encompass  many  of  the  standard  Java  libraries. 


2.  MIL  3,  Inc.  •  3400  International  Drive,  NW  •  Washington,  DC  •  20008.  http://www.mil3.com/ 
products/modeler/simcycle.html. 

3.  UCB/LBNL/VINT  Network  Simulator  -  ns  (version  2),  http://mash.cs.berkeley.edu/ns/ns.html 
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APPENDIX  A.  MPS  AND  SMPS  OOA  MODEL  DIAGRAMS 


Figure  A-l.  MPS  Object  Information  Model 


MPS/RTE 


Figure  A-2.  SMPS  Object  Information  Model 


Created 

tid  =  create  thread(id) 


Starting 

%g  RTE1:  ready  (tid) 


Waiting  for  Message 
%g  TH3:block(tid) 


Transfer  Msg 
if  tbuff  nonempty{ 
msg  =  get  message 
msg.dest.put(msg) 
if  msg.deststate  =  WFM  { 
act  =  msg.dest 
time  +=  get+put+notify 

} 

else 

time  +=  get+put 

} 

%g  TIM1(TH3,  time,  id) 


Interrupted! 

%g  RTE1:ready(tid) 


CtxToRunning2 
%g  TIM1(TH3,  now+ctxtm) 


CtxToRunningl  > 
%gTIM1(TH3,  now+ctxtm)y 


Interrupted2 
%g  RTE1:ready(tid) 


Getting  Message 
if  no  message 
%g  TH4:wait(id) 
slse{ 

%g  TH3:continue(id) 


/  Timeout 

mat  =  msg. activation  time 
i — '  %g  TIM1  :set  timer 
TH^  (TH1,  mat,  tid) 
n°  \%g  TH3:block(tid) 


Figure  A-3.  SMPS  Timer  State  Model 


(  Getting  Message 
if  empty  message  buffer 
%g  TH4:wait(id) 
else{ 

msg  =  get  msg 
gmt  =  sclock  +  get  time 
%g  TIM1:set  timer 
V  (TH3,  gmt,  id)  } 


f  CtxSwToRunningl  N 
\%g TH1(TH3,  now+ctxT m). 


Transferring  Msgs 
set  priority  to  max 
while  non-empty  tbuff  { 
m  =  tbuff.get 
dest.buff.put(m) 
if  m.dest.state=WFM  { 
time  =  get+put+notify 
%g  TH1:ready(m.dest) 

} 

else 

time  =  get+put 

} 

%g  TIM1:set  timer 
V(TH3,  now+time) 


Interrupted 
%g  RTE1:ready(tid) 


f  CtxSwToRunning2 
raise  priority 

%g  TH1(TH3,  now+ctxTm)/ 


f  Waiting  for  Message 
l%g  TH3:block(tid) 


f  Preempted 
%g  TIM2:cancel(e  id) 
consumed  =  sclock()-start 
Wem -=  consumed 


f  Starting 

%g  TH1 :  ready (tid) 
\set  priority  to  max 


/  Activating 

start  =  sclock 
restorePri 

\%gTIM1(TH3,  now+Trem) 


Created 

tid  =  %create  thread(id) 


f  Activate 

set  pri  to  default 
update  eclock 
msg.activate() 

TH3  activatefidt 


Figure  A-4.  SMPS  Activator  State  Model 


Figure  A-5.  SMPS  Run-Time  Executive  State  Model 
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Figure  A-6.  SMPS  Thread  State  Model 
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Figure  A-7.  Multiprocessor-based  MPS  Object  Information  Model 


f  Blocking 

%g  TH3:block(rid) 
find  CPU  (R17)  with  R16==rid 
tid  =  get 

highest  pri  ready  thread 
if  tid  valid 
R17.R16  =  tid 
%g  TH2:run(tid) 
else 

R17.R16  =  undefined 
\%g  RTE4:idle 


RTE2:idle  RTE3:block 


RTE1: 

ready(tid) 


RTE2:idle 


'  Checking 

rid  =  running  thread 
if  tid  higher  pri  than  rid  { 
find  CPU  (R17)  with  R16==rid 
%g  TH1:ready(rid) 
running  thread  =  tid 
R17.R16  =  tid 
%g  TH2:run(tid) 

} 


Figure  A-8.  Multiprocessor-based  MPS  Run-Time 
Executive  State  Model 
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Figure  A-9.  Domain  Model  for  a  Simulated  MPS-based  Distributed 

Application 
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APPENDIX  B.  MPPM  SOURCE  CODE  EXAMPLES 


public  final  class  ClockRes2 

{ 

static  long[]  time  =  new  long [1000000]; 


} 


public  static  void  main (String  args[]) 

{ 

int  count  =  0; 

double  sum  =  0.0; 

for  (int  test=0;  test<10;  test++) 

{ 

for  (int  idx=0;  idx<time . length;  idx++) 
time[idx]  =  System. currentTimeMillis () ; 
for  (int  idx=l;  idxctime . length;  idx++) 

{ 

if  (time[idx]  >  time[idx-l]) 

{ 


} 


count++; 

long  diff  =  timefidx]  -  time[idx-l]; 
sum  =  sum  +  (double) (timefidx] 

-  time [idx-1] ) ; 


} 


} 

System. out .println ( "resolution:  " 

+  (sum/ (double) count) 


} 


+  "  ms")  ; 


Figurre  B-l .  Program  to  Determine  the  Resolution  of  the 
Fundamental  Time  Unit  Returned  by  Java  System.  currentTimeMillis 
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/’**  Get  the  current  system  time. 

★ 

*  @return  current  system  time  in  milliseconds. 
*/ 

public  long  millis() 

{ 

double  time  =  Clock. get ()  //sim  clock; 
time  =  Math. floor (Tcr*Math. floor (time/Tcr) ) ; 
return  (long)  time; 

} 


Figure  B-2.  The  SMPS  Model  of  the  Java 
System.  currentTimeMillis  Method  in  class  MpsRealClock 
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public  final  class  DelayResolution  extends  Thread 

{ 

static  final  int  N  =  50,  trials  =  30; 

static  final  long  [] 

time  =  new  long  [N  *  trials], 

mtime  =  new  long  [N  *  trials]; 

static  int  ctr  =  0; 

public  static  void  main (String  args[]) 

{  ' 

object  t  =  new  object (); 

for  (int  idx  =  0;  idx  <  N;  idx++) 

for  (int  trial  =  0;  trial  <  trials;  trial++) 

{ 

rtime[ctr]  =  (long  ) (idx  +  1) ; 
mtime [ctr]  =  t .Wait (rtime [ctr] ) ; 
ctr++; 

} 

System. out. print In ("0,  " ); 

for  (int  idx  =  0;  idx  <  rtime . length;  idx++) 
System. out .print In ( " " 

+  rtimefidx]  +  ",  "  +  mtime[idx]); 


class  object  extends  Object 

{ 

public  synchronized  long  Wait (long  time) 

{ 

long  start  =  0; 
try 
{ 

start  =  System. currentTimeMillis () ; 
wait (time) ; 

return  System. currentTimeMillis ( )  -  start; 

} 

catch  (InterruptedException  e) 

{ 

System. out . println (e . toString  ( ) ) ; 
return  -1; 

} 


Figure  B-3.  Program  to  Examine  the  Resolution  of  the 
Java  wait  Statement 
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//%%/**  Execution  time  estimate  of  1st  path.*/ 
//%%private  static  final  double 
/ /%%Vappend_lmf  =  "method. mipubvlpMf" 

//%%  +  "cond.iVbEqcVbMf" 

//%%  +  2*"assign. iloloMf " 

//%%  +  "MpsNodeTO. updateNextNullMf " ; 

//%%/**  Execution  time  estimate  of  2nd  path.*/ 
//%%private  static  final  double 
//%%Vappend_2mf  =  "method. mipubvlpMf " 

//%%  +  "cond.iVbEqcVbMf" 

//%%  +  "assign. iloloMf " 

//%%  +  "MpsNodeTO. updateNextMf " 

//%%  +  "MpsNodeTO. updateNextNullMf"; 

/**  Appends  MpsMessage  to  buffer. 

*  @param  msg  the  message  to  be  appended.  */ 
final  void  append (CpuCharger  cc,  MpsMessage  msg] 

if  (front  ==  null) 

{ 

back  =  msg; 

front  =  msg; 

msg . updateNext (null) ; 

/  /  %  %  cc .  charge  ( Vappend__lmf )  ; 


else 


back. updateNext (msg) ; 
msg. updateNext (null) ; 
back  =  msg; 

//%%cc. charge (Vappend  2mf) 


Figure  B-4.  MpsFifo. append  Method  Before  ETE  Inlining 
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/**  Execution  time  estimate  of  1st  path.*/ 
private  static  final  double 
Vappend_lmf  =  3 . 320018450419108E-4 
+  2.449154853820801E-4 
+  2*4. 8053264617 91992E-4 
+  4.1353702545166016E-4; 

/**  Execution  time  estimate  of  2nd  path.*/ 
private  static  final  double 
Vappend_2mf  =  3 . 320018450419108E-4 
+  2.449154853820801E-4 
+  4.805326461791992E-4 
+  5.21540641784668E-4 
+  4. 135370254516601 6E -4; 

/**  Appends  MpsMessage  to  buffer. 

*  @param  msg  the  message  to  be  appended.  */ 
final  void  append (CpuCharger  cc,  MpsMessage  msg) 
{ 

if  (front  ==  null) 

{ 

back  =  msg; 

front  =  msg; 

msg . updateNext (null)  ; 

cc. charge ( Vappend_lmf ) ; 

} 

else 

{ 

back . updateNext (msg) ; 
msg. updateNext (null) ; 
back  =  msg; 

cc. charge (Vappend_2mf ) ; 

} 


Figure  B-5.  MpsFifo.  append  Method  After  ETE  Inlining 
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P2:NoRice(P  Id)  PI  :continue(P  Id) 


Figure  C-2.  Philosopher  State  Model 


9i 


■TK2:continue(ld) 


Idle 

Pld  =  R6.22 
%g  PI  (Pld) 


TK1:request(LH  Id,  Id)  I 

j  TK2:continue(ld) 


TK3:none  available(ld) 


Backing  Off 
Pld  =  R6 

%g  P2:No  Rice(Pld) 


Figure  C-3.  Token  State  Model 


{  Cleaning  Up 
Cld  =  R6 

%g  C2:releas(Cld) 
Cld  =  R6.R2.R1  .R2 
%g  C2:releas(Cld) 
%g  TK_A4(ld) 

^%g  TK2:continue(ld) 
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Figure  C-4.  Token  Assigner  State  Model 
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C1:request(T  Id,  Id)  C2:release(ld) 


Owned 

%gTK2:continue(Tkld) 


C1:request(Tkld,  | 

Id)  C1:request(Tkld,  Id) 


Figure  C-5.  Chopstick  State  Model 


Figure  C-6.  Rice  State  Model 
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APPENDIX  D.  DINING  PHILOSOPHER  PROGRAM  EXECUTION  TRACES 


D.l.  APPLICATION-LEVEL  TRACE 


This  section  contains  the  complete  execution  trace  for  the  application-level  activi¬ 


ties  in  the  SMPS  DP  program.  Each  application-level  trace  statement  has  a  line  number,  the 


simulation  time  in  brackets,  the  object  state,  and  may  also  have  a  message  pertaining  to  the 


state. 


1  [0.0000]  TOK_A  IDLE 

2  [0.0000]  Plato  CREATED 

3  [0.0000]  Hegel  CREATED 

4  [0.0000]  Decartes  CREATED 

5  [0.0000]  Lao  Tsu  CREATED 

6  [0.0000]  Socrates  CREATED 

7  [1.4017]  Plato  WAITING:  %g  TK_A1 (Plato)  to  Token_A 

8  [1.4093]  Hegel  WAITING:  %g  TK_A1 (Hegel)  to  Token_A 

9  [1.4170]  Decartes  WAITING:  %g  TK_A1 (Decartes)  to  Token_A 

10  [1.4247]  Lao  Tsu  WAITING:  %g  TK_A1 (Lao  Tsu)  to  Token_A_ 

11  [1.4323]  Socrates  WAITING:  %g  TK_A1 (Socrates)  to  Token_A 

12  [1.4400]  TOK_A  REQUESTING:  TOK_0  is  avail:  %g  TK1(CS  0)  to  TOKO 

13  [1.4400]  TOK_A  IDLE 

14  [1.4476]  TOK_A  REQUESTING:  TOK_l  is  avail:  %g  TKl(CSl)  to  TOK  1 

15  [1.4476]  TOK_A  IDLE 

16  [1.4553]  TOK_A  REQUESTING:  TOK_2  is  avail:  %g  TK1(CS_2)  to  TOK  2 

17  [1.4553]  TOK_A  IDLE 

18  [1.4629]  TOK_A  REQUESTING:  TOK_3  is  avail:  %g  TK1(CS_3)  to  TOK  3 

19  [1.4629]  TOK_A  IDLE 

20  [1.4706]  TOK_A  REQUESTING:  no  avail  tokens,  Socrates  pending 

21  [1.4706]  TOK_A  IDLE 

22  [1.4723]  TOK_0  WAITING_FOR_LC :  %g  Cl  to  CS_0 

23  [1.4799]  TOK_l  WAITING_FOR_LC :  %g  Cl  to  CS_1 

24  [1.4876]  TOK_2  WAITING_FOR_LC :  %g  Cl  to  CS_2 

25  [1.4952]  TOK_3  WAITING_FOR_LC :  %g  Cl  to  CS_3 

26  [1.5029]  CS_0  OWNED:  %g  TK2  to  TOK_0 

27  [1.5105]  CS_1  OWNED:  %g  TK2  to  TOK_l 

28  [1.5182]  CS_2  OWNED:  %g  TK2  to  TOK_2 

29  [1.5258]  CS_3  OWNED:  %g  TK2  to  TOK_3 

30  [1.5335]  TOK_0  WAITING_FOR_RC :  %g  Cl  to  CS_4 

31  [1.5411]  TOK_l  WAITING_FOR_RC:  %g  Cl  to  CS_0 

32  [1.5488]  TOK_2  WAITING_FOR_RC :  %g  Cl  to  CS_1 

33  [1.5564]  TOK_3  WAITING_FOR_RC :  %g  Cl  to  CS_2 

34  [1.5641]  CS_4  OWNED:  %g  TK2  to  TOK_0 

35  [1.5718]  CS_0  RESERVED 

36  [1.5734]  CS_1  RESERVED 

37  [1.5751]  CS_2  RESERVED 

38  [1.5771]  TOK_0  WAITING_FOR_RICE :  %g  R1  to  Rice 

39  [1.5851]  RICE  %g  TK2  to  TOK_0,  9  bites  remaining 

40  [1.5930]  TOK_0  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Plato 

41  [1.6010]  Plato  EAT:  scheduling  PI  to  self  at  150ms 

42  [151.4095]  Plato  RELINQUISHING:  %g  TK2  to  TOK_0 

43  [151.4174]  TOK_0  CLEANING_UP :  %g  C2  to  CS_0 

44  [151.4174]  TOK_0  CLEANING_UP :  %g  C2  to  CS_4 

45  [151.4174]  TOK_0  CLEANING_UP :  %g  TK_A4  to  Token_A 
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46  [151.4421]  CS_0  REQUESTING:  %g  Cl  self-event 

47  [151.4421]  CS_0  OWNED:  %g  TK2  to  TOK_l 

48  [151.4497]  CS_4  UNOWNED 

49  [151.4514]  TOK_A  RELINQUISHING:  TOK_0  avail,  %g  TK_A2  self-event 

50  [151.4514]  TOK_A  IDLE:  %g  TK_A1 (Socrates)  to  self 

51  [151.4591]  Plato  THINK:  scheduling  PI  to  self  at  390ms 

52  [151.4689]  TOK_l  WAITING_FOR_RICE :  %g  R1  to  Rice 

53  [152.8766]  T0K_A  REQUESTING:  TOK  0  is  avail:  %g  TK1 (CS  4)  to  TOK  0 

54  [152.8766]  T0K_A  IDLE 

55  [152.8842]  RICE  %g  TK2  to  TOK_l,  8  bites  remaining 

56  [152.8919]  TOK_0  WAITING_FOR_LC :  %g  Cl  to  CS_4 

57  [152.8995]  TOK_l  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Hegel 

58  [152.9072]  CS_4  OWNED:  %g  TK2  to  TOK_0 

59  [152.9148]  Hegel  EAT:  scheduling  PI  to  self  at  290ms 

60  [152.9251]  TOK_0  WAITING_FOR_RC :  %g  Cl  to  CS_3 

61  [154.3331]  CS_3  RESERVED 

62  [291.4098]  Hegel  RELINQUISHING:  %g  TK2  to  TOK1 

63  [291.4177]  T0K_1  CLEANING_UP:  %g  C2  to  CS_1 

64  [291.4177]  T0K_1  CLEANING_UP:  %g  C2  to  CS_0 

65  [291.4177]  T0K_1  CLEANING_UP:  %g  TK_A4  to  Token  A 

66  [291.4424]  CS_1  REQUESTING:  %g  Cl  self-event 

67  [291.4424]  CS_1  OWNED:  %g  TK2  to  TOK  2 

68  [291.4500]  CS_0  UNOWNED 

69  [291.4517]  T0K_A  RELINQUISHING:  TOK  1  avail,  %g  TK  A2  self-event 

70  [-291.4517]  TOK_A  IDLE 

71  [291.4534]  Hegel  THINK:  scheduling  PI  to  self  at  531ms 

72  [291.4648]  TOK_2  WAITING_FOR_RICE :  %g  R1  to  Rice 

73  [291.4728]  RICE  %g  TK2  to  TOK_2,  7  bites  remaining 

74  [291.4807]  TOK_2  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Decartes 

75  [291.4887]  Decartes  EAT:  scheduling  PI  to  self  at  431ms 

76  [391.4098]  Plato  WAITING:  %g  TK_A1 (Plato)  to  Token_A 

77  [391.4177]  TOK_A  REQUESTING:  TOK  1  is  avail:  %g  TK1 (CS  0)  to  TOK  1. 

78  [391.4177]  TOK_A  IDLE  ~  “ 

79  [391.4257]  TOK_l  WAITING_FOR_LC :  %g  Cl  to  CS  0 

80  [391.4336]  CS_0  OWNED:  %g  TK2  to  TOK_l 

81  [391.4415]  TOK_l  WAITING_FOR_RC :  %g  Cl  to  CS  4 

82  [391.4495]  CS_4  RESERVED 

83  [432.4098]  Decartes  RELINQUISHING:  %g  TK2  to  TOK  2 

84  [432.4177]  T0K_2  CLEANINGJJP:  %g  C2  to  CS  2 

85  [432.4177]  T0K_2  CLEANING_UP :  %g  C2  to  CS_1 

86  [432.4177]  TOK_2  CLEANING_UP:  %g  TK_A4  to  Token  A 

87  [432.4424]  CS_2  REQUESTING:  %g  Cl  self-event 

88  [432.4424]  CS_2  OWNED:  %g  TK2  to  TOK  3 

89  [432.4500]  CS_1  UNOWNED 

90  [432.4517]  T0K_A  RELINQUISHING:  TOK  2  avail,  %g  TK  A2  self-event' 

91  [432.4517]  TOK_A  IDLE 

92  [432.4534]  Decartes  THINK:  scheduling  PI  to  self  at  671ms 

93  [432.4648]  TOK_3  WAITING_FOR_RICE :  %g  R1  to  Rice 

94  [432.4728]  RICE  %g  TK2  to  TOK_3,  6  bites  remaining 

95  [432.4807]  TOK_3  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Lao  Tsu 

96  [432.4887]  Lao  Tsu  EAT:  scheduling  PI  to  self  at  671ms 

97  [532.4098]  Hegel  WAITING:  %g  TK_A1 (Hegel)  to  Token_A 

98  [532.4177]  T0K_A  REQUESTING:  TOK  2  is  avail:  %g  TK1 (CS  1)  to  TOK  2 

99  [532.4177]  TOK_A  IDLE  "  “ 

100  [532.4257]  TOK_2  WAITING_FOR_LC :  %g  Cl  to  CS  1 

101  [532.4336]  CS_1  OWNED:  %g  TK2  to  TOK  2 

102  [532.4415]  TOK_2  WAITING_FOR_RC :  %g  Cl  to  CS  0 

103  [532.4495]  CS_0  RESERVED 

104  [672.4098]  Lao  Tsu  RELINQUISHING:  %g  TK2  to  TOK_3 

105  [673.8227]  Decartes  WAITING:  %g  TK  A1 (Decartes)  to  Token  A 

106  [673.8304]  T0K_3  CLEANING_UP:  %g  C2  to  CS  3  - 

107  [673.8304]  TOK_3  CLEANING_UP :  %g  C2  to  CS  2 

108  [673.8304]  TOK_3  CLEANING_UP :  %g  TK_A4  to  Token_A 

109  [673.8551]  TOK_A  REQUESTING:  no  avail  tokens.  Decartes  pending 
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110  [673.8551]  TOK_A  IDLE 

111  [673.8568]  CS_3  REQUESTING:  %g  Cl  self-event 

112  [673.8568]  CS_3  OWNED:  %g  TK2  to  TOK_0 

113  [673.8644]  CS_2  UNOWNED 

114  [673.8661]  TOK_A  RELINQUISHING:  TOK_3  avail,  %g  TK  A2  self-event 

115  [673.8661]  TOK_A  IDLE:  %g  TK_A1 ( Decartes )  to  self 

116  [673.8737]  Lao  Tsu  THINK:  scheduling  PI  to  self  at  1171ms 

117  [673.8836]  TOK_0  WAITING_FOR_RICE :  %g  R1  to  Rice 

118  [675.2912]  TOK_A  REQUESTING:  TOK_3  is  avail:  %g  TK1 (CS  2)  to  TOK  3 

119  [675.2912]  TOK_A  IDLE 

120  [675.2989]  RICE  %g  TK2  to  TOK_0,  5  bites  remaining 

121  [675.3066]  TOK_3  WAITING_FOR_LC :  %g  Cl  to  CS_2 

122  [675.3142]  TOK_0  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Socrates 

123  [675.3219]  CS_2  OWNED:  %g  TK2  to  TOK_3 

124  [675.3295]  Socrates  EAT:  scheduling  PI  to  self  at  921ms 

125  [675.3398]  TOK_3  WAITING_FOR_RC :  %g  Cl  to  CS_1 

126  [676.7478]  CS_1  RESERVED 

127  [922.4098]  Socrates  RELINQUISHING:  %g  TK2  to  TOK_0 

128  [922.4177]  TOK_0  CLEANING_UP :  %g  C2  to  CS_4 

129  [922.4177]  TOK_0  CLEANING_UP:  %g  C2  to  CS_3 

130  [922.4177]  TOK_0  CLEANING_UP :  %g  TK_A4  to  Token  A 

131  [922.4424]  CS_4  REQUESTING:  %g  Cl  self-event 

132  [922.4424]  CS_4  OWNED:  %g  TK2  to  TOK  1 

133  [922.4500]  CS_3  UNOWNED 

134  [922.4517]  TOK_A  RELINQUISHING:  TOK_0  avail,  %g  TK_A2  self-event 

135  [922.4517]  TOK_A  IDLE 

136  [922.4534]  Socrates  THINK:  scheduling  PI  to  self  at  1421ms 

137  [922.4648]  TOK_l  WAITING_FOR_RICE :  %g  R1  to  Rice 

138  [922.4728]  RICE  %g  TK2  to  TOK__l,  4  bites  remaining 

139  [922.4807]  TOK_l  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Plato 

140  [922.4887]  Plato  EAT:  scheduling  PI  to  self  at  1071ms 

141  [1072.4098]  Plato  RELINQUISHING:  %g  TK2  to  TOK1 

142  [1072.4177]  TOK_l  CLEANING_UP:  %g  C2  to  CS  0 

143  [1072.4177]  TOK_l  CLEANING_UP :  %g  C2  to  CS_4 

144  [1072.4177]  TOK_l  CLEANING_UP :  %g  TK_A4  to  Token_A 

145  [1072.4424]  CS_0  REQUESTING:  %g  Cl  self-event 

146  [1072.4424]  CS_0  OWNED:  %g  TK2  to  TOK_2 

147  [1072.4500]  CS_4  UNOWNED 

148  [1072.4517]  T0K_A  RELINQUISHING:  TOK  1  avail,  %g  TK  A2  self-event 

149  [1072.4517]  TOK_A  IDLE 

150  [1072.4534]  Plato  THINK:  scheduling  PI  to  self  at  1312ms 

151  [1072.4654]  TOK_2  WAITING_FOR_RICE :  %g  R1  to  Rice 

152  [1072.4733]  RICE  %g  TK2  to  T0K_2 ,  3  bites  remaining 

153  [1072.4813]  TOK_2  WAITING_FOR_PHILOSOPHER :  %g  PI  to  Hegel 

154  [1072.4892]  Hegel  EAT:  scheduling  PI  to  self  at  1212ms 

155  [1172.4098]  Lao  Tsu  WAITING:  %g  TK_A1 (Lao  Tsu)  to  Token_A 

156  [1172.4177]  TOK_A  REQUESTING:  TOKO  is  avail:  %g  TK1 (CS  3)  to  TOK  0 

157  [1172.4177]  TOK_A  IDLE 

158  [1172.4257]  TOK_0  WAITING_FOR_LC :  %g  Cl  to  CS_3 

159  [1172.4336]  CS_3  OWNED:  %g  TK2  to  TOK_0 

160  [1172.4415]  TOK_0  WAITING_FOR_RC :  %g  Cl  to  CS  2 

161  [1172.4495]  CS_2  RESERVED 

162  [1213.4098]  Hegel  RELINQUISHING:  %g  TK2  to  TOK_2 

163  [1213.4177]  TOK_2  CLEANING_UP :  %g  C2  to  CS  1 

164  [1213.4177]  T0K_2  CLEANINGJJP:  %g  C2  to  CS_0 

165  [1213.4177]  TOK_2  CLEANING_UP :  %g  TK_A4  to  Token_A 

166  [1213.4424]  CS_1  REQUESTING:  %g  Cl  self-event 

167  [1213.4424]  CS_1  OWNED:  %g  TK2  to  TOK_3 

168  [1213.4500]  CS_0  UNOWNED 

169  [1213.4517]  T0K_A  RELINQUISHING:  TOK  2  avail,  %g  TK  A2  self-event 

170  [1213.4517]  TOK_A  IDLE 

171  [1213.4534]  Hegel  THINK:  scheduling  PI  to  self  at  1453ms 

172  [1213.4655]  TOK_3  WAITING_FOR_RICE :  %g  R1  to  Rice 

173  [1213.4734]  RICE  %g  TK2  to  TOK_3,  2  bites  remaining 
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174  [1213.4814]  T0K_3  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Decartes 

175  [1213.4893]  Decartes  EAT:  scheduling  PI  to  self  at  1353ms 

176  [1313.4098]  Plato  WAITING:  %g  TK_A1 (Plato)  to  Token  A 

177  [1313.4177]  TOK_A  REQUESTING:  TOK_l  is  avail:  %g  TK1 (CS  0)  to  TOK  1 

178  [1313.4177]  TOK_A  IDLE 

179  [1313.4257]  TOK_l  WAITING_FOR_LC :  %g  Cl  to  CS  0 

180  [1313.4336]  CS_0  OWNED:  %g  TK2  to  T0K_1 

181  [1313.4415]  TOK_l  WAITING_FOR_RC :  %g  Cl  to  CS  4 

182  [1313.4495]  CS_4  OWNED:  %g  TK2  to  TOK_l 

183  [1313.4574]  TOK_l  WAITING_FOR_RICE :  %'g  R1  to  Rice 

184  [1313.4654]  RICE  %g  TK2  to  TOK_l,  1  bites  remaining 

185  [1313.4733]  TOK_l  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Plato 

186  [1313.4812]  Plato  EAT:  scheduling  PI  to  self  at  1462ms 

187  [1354.4098]  Decartes  RELINQUISHING:  %g  TK2  to  TOK  3 

188  [1354.4177]  TOK_3  CLEANINGJJP:  %g  C2  to  CS_2 

189  [1354.4177]  T0K_3  CLEANING_UP:  %g  C2  to  CS_1 

190  [1354.4177]  T0K_3  CLEANING_UP:  %g  TK_A4  to  Token  A 

191  [1354.4424]  CS_2  REQUESTING:  %g  Cl  self-event 

192  [1354.4424]  CS__2  OWNED:  %g  TK2  to  TOK_0 

193  [1354.4500]  CS_1  UNOWNED 

194  [1354.4517]  TOK_A  RELINQUISHING:  TOK  3  avail,  %g  TK  A2  self-event 

195  [1354.4517]  T0K_A  IDLE 

196  [1354.4534]  Decartes  THINK:  scheduling  PI  to  self  at  1593ms 

197  [1354.4655]  TOK_0  WAITING_FOR_RICE :  %g  R1  to  Rice 

198  [1354.4734]  RICE  %g  TK2  to  TOK_0,  0  bites  remaining 

199  [1354.4814]  TOK_0  WAITING_FOR_PHILOSOPHER:  %g  PI  to  Lao  Tsu 

200  [1354.4893]  Lao  Tsu  EAT:  scheduling  PI  to  self  at  1593ms 

201  [1422.4098]  Socrates  WAITING:  %g  TK_A1 (Socrates)  to  Token  A 

202  [1422.4177]  TOK_A  REQUESTING:  TOK  2  is  avail:  %g  TK1(CS  4)  to  TOK  2 

203  [1422.4177]  TOK_A  IDLE  - 

204  [1422.4257]  TOK_2  WAITING_FOR_LC :  %g  Cl  to  CS  4 

205  [1422.4336]  CS_4  RESERVED 

206  [1454.4098]  Hegel  WAITING:  %g  TK_A1 (Hegel)  to  Token  A 

207  [1454.4177]  TOK_A  REQUESTING:  TOK  3  is  avail:  %g  TKllCS  1)  to  TOK  3 

208  [1454.4177]  TOK_A  IDLE  -  _ 

209  [1454.4257]  TOK_3  WAITING_FOR_LC :  %g  Cl  to  CS  1 

210  [1454.4336]  CS_1  OWNED:  %g  TK2  to  TOK_3 

211  [1454.4415]  TOK_3  WAITING_FOR_RC :  %g  Cl  to  CS  0 

212  [1454.4495]  CS_0  RESERVED 

213  [1463.4098]  Plato  RELINQUISHING:  %g  TK2  to  TOK  1 

214  [1463.4177]  TOK_l  CLEANING_UP:  %g  C2  to  CS  0 

215  [1463.4177]  TOK_l  CLEANING_UP :  %g  C2  to  CS_4 

216  [1463.4177]  TOK_l  CLEANING_UP:  %g  TK_A4  to  Token  A 

217  [1463.4424]  CS_0  REQUESTING:  %g  Cl  self-event 

218  [1463.4424]  CS_0  OWNED:  %g  TK2  to  TOK_3 

219  [1463.4500]  CS_4  REQUESTING:  %g  Cl  self-event 

220  [1463.4500]  CS_4  OWNED:  %g  TK2  to  TOK_2 

221  [1463.4577]  TOK_A  RELINQUISHING:  TOK  1  avail,  %g  TK  A2  self-event 

222  [1463.4577]  TOK_A  IDLE 

223  [1463.4594]  Plato  THINK:  scheduling  PI  to  self  at  1703ms 

224  [1463.4711]  TOK_3  WAITING_FOR_RICE :  %g  R1  to  Rice 

225  [1463.4788]  TOK_2  WAITING_FOR_RC :  %g  Cl  to  CS  3 

226  [1463.4941]  CS_3  RESERVED 

227  [1463.4961]  TOK_3  BACKING_OFF :  %g  P2  to  Hegel 

228  [1463.4961]  TOK_3  CLEANING_UP :  %g  C2  to  CS  1 

229  [1463.4961]  TOK_3  CLEANINGJJP:  %g  C2  to  CS  0 

230  [1463.4961]  T0K_3  CLEANING_UP :  %g  TK  A4  to  Token  A 

231  [1463.5264]  Hegel  NO_RICE 

232  [1463.5281]  CS_1  UNOWNED 

233  [1463.5298]  CS_0  UNOWNED 

234  [1463.5315]  TOK_A  RELINQUISHING:  TOK  3  avail,  %g  TK  A2  self-event 

235  [1463.5315]  T0K_A  IDLE 

236  [1594.4098]  Lao  Tsu  RELINQUISHING:  %g  TK2  to  TOK  0 

237  [1595.8230]  Decartes  WAITING:  %g  TK  A1 (Decartes)  to  Token  A 
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238 

[1595.8307] 

239 

[1595.8307] 

240 

[1595.8307] 

241 

[1595.8554] 

242 

[1595.8554] 

243 

[1595.8630] 

244 

[1595.8630] 

245 

[1595.8707] 

246 

[1595.8724] 

247 

[1595.8724] 

248 

[1595.8741] 

249 

[1595.8852] 

250 

[1595.8928] 

251 

[1595.9005] 

252 

[1595.9158] 

253 

[1595.9234] 

254 

[1595.9234] 

255 

[1595.9234] 

256 

[1595.9234] 

257 

[1595.9538] 

258 

[1595.9615] 

259 

[1595.9631] 

260 

[1595.9648] 

261 

[1595.9665] 

262 

[1595.9665] 

263 

[1595.9702] 

264 

[1595.9861] 

265 

[1595.9861] 

266 

[1595.9861] 

267 

[1595.9861] 

268 

[1596.0164] 

269 

[1596.0181] 

270 

[1596.0198] 

271 

[1596.0215] 

272 

[1596.0215] 

273 

[1704.4098] 

274 

[1704.4177] 

275 

[1704.4177] 

276 

[1704.4257] 

277 

[1704.4336] 

278 

[1704.4415] 

279 

[1704.4495] 

280 

[1704.4574] 

281 

[1704.4733] 

282 

[1704.4733], 

283 

[1704.4733] 

284 

[1704.4733] 

285 

[1704.5036] 

286 

[1704.5053] 

287 

[1704.5070] 

288 

[1704.5087] 

289 

[1704.5087] 

290 

[2094.4095] 

291 

[2094.4174] 

292 

[2094.4174] 

293 

[2094.4254] 

294 

[2094.4333] 

295 

[2094.4412] 

296 

[2094.4492] 

297 

[2094.4571] 

298 

[2094.4730] 

299 

[2094.4730] 

300 

[2094.4730] 

301 

[2094.4730] 

TOK_0  CLEANING_UP:  %g  C2  to  CS_3 

TOK_0  CLEANING_UP:  %g  C2  to  CS_2 

TOK_0  CLEANING_UP:  %g  TK_A4  to  Token_A 

TOK_A  REQUESTING:  T0K_1  is  avail:  %g  TK1(CS_2)  to  T0K_1 

TOK_A  IDLE 

CS_3  REQUESTING:  %g  Cl  self-event 
CS_3  OWNED:  %g  TK2  to  T0K_2 
CS_2  UNOWNED 

TOK_A  RELINQUISHING:  TOK_0  avail,  %g  TK_A2  self-event 
TOK_A  IDLE 

Lao  Tsu  THINK:  scheduling  PI  to  self  at  2093ms 

TOK_l  WAITING_FOR_LC:  %g  Cl  to  CS_2 

TOK_2  WAITING_FOR_RICE :  %g  R1  to  Rice 

CS_2  OWNED:  %g  TK2  to  TOK_l 

TOK_l  WAITING_FOR_RC :  %g  Cl  to  CS_1 

TOK_2  BACKING_OFF:  %g  P2  to  Socrates 

TOK_2  CLEANING_UP:  %g  C2  to  CS_4 

TOK_2  CLEANING_UP :  %g  C2  to  CS_3 

TOK_2  CLEANING_UP:  %g  TK_A4  to  Token_A 

CS_1  OWNED:  %g  TK2  to  TOK_l 

Socrates  NO_RICE 

CS_4  UNOWNED 

CS_3  UNOWNED 

TOK_A  RELINQUISHING:  T0K_2  avail,  %g  TK_A2  self-event 
TOK_A  IDLE 

T0K_1  WAITING_FOR_RICE :  %g  R1  to  Rice 
TOK_l  BACKING_OFF :  %g  P2  to  Decartes 
TOK_l  CLEANING_UP:  %g  C2  to  CS_2 
TOK_l  CLEANING_UP :  %g  C2  to  CS_1 
TOK_l  CLEANINGJUP:  %g  TK_A4  to  Token_A 
Decartes  NO_RICE 
CS_2  UNOWNED 
CS_1  UNOWNED 

TOK_A  RELINQUISHING:  T0K_1  avail,  %g  TK_A2  self-event 
TOK_A  IDLE 

Plato  WAITING:  %g  TK_A1 (Plato)  to  Token_A 

TOK_A  REQUESTING:  TOK_0  is  avail:  %g  TK1(CS_0)  to  TOK_0 

TOK_A  IDLE 

TOK_0  WAITING_FOR_LC:  %g  Cl  to  CS_0 
CS_0  OWNED:  %g  TK2  to  TOK_0 
TOK_0  WAITING_FOR_RC:  %g  Cl  to  CS_4 
CS_4  OWNED:  %g  TK2  to  TOK_0 
TOK_0  WAITING_FOR_RICE:  %g  R1  to  Rice 
TOK_0  BACKING_OFF :  %g  P2  to  Plato 
TOK_0  CLEANING_UP :  %g  C2  to  CS_0 
TOK_0  CLEANING_UP :  %g  C2  to  CS_4 
TOK_0  CLEANINGJJP:  %g  TK_A4  to  Token_A 
Plato  NO_RICE 
CS_0  UNOWNED 
CS_4  UNOWNED 

TOK_A  RELINQUISHING:  TOK_0  avail,  %g  TK_A2  self-event 
TOK  A  IDLE 


Lao  Tsu  WAITING:  %g  TK_A1 (Lao  Tsu)  to  Token_A 

TOK_A  REQUESTING:  TOK_0  is  avail:  %g  TK1(CS_3)  to  TOK_0 

TOK_A  IDLE 

TOK_0  WAITING_FOR_LC:  %g  Cl  to  CS_3 
CS_3  OWNED:  %g  TK2  to  TOK_0 
TOK_0  WAI TIN G_FOR_RC :  %g  Cl  to  CS_2 
CS_2  OWNED:  %g  TK2  to  TOK_0 
TOK_0  WAITING_FOR_RICE:  %g  R1  to  Rice 
TOK_0  BACKING_OFF :  %g  P2  to  Lao  Tsu 
TOK  0  CLEANING  UP:  %g  C2  to  CS_3 

%g  C2  to  CS_2 
%g  TKA4  to  Token  A 


TOK_0  CLEANING_UP 
TOK  0  CLEANING  UP 
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302  [2094.5033]  Lao  Tsu  NO__RICE 

303  [2094.5050]  CS_3  UNOWNED 

304  [2094.5067]  CS_2  UNOWNED 

305  [2094.5084]  TOK_A  RELINQUISHING:  TOK_0  avail,  %g  TK  A2  self-event 

306  [2094.5084]  TOK_A  IDLE 

307  [2094.5104]  Plato  spent  450  ms  eating  3  bites  of  rice  and  750  ms 

thinking 

308  [2094.5104]  Hegel  spent  300  ms  eating  2  bites  of  rice  and  500  ms 
thinking 

309  [2094.5104]  Decartes  spent  300  ms  eating  2  bites  of  rice  and  500  ms 
thinking 

310  [2094.5104]  Lao  Tsu  spent  500  ms  eating  2  bites  of  rice  and  1000  ms 
thinking 

311  [2094.5104]  Socrates  spent  250  ms  eating  1  bites  of  rice  and  500  ms 
thinking 

D.2  SMPS-LEVEL  TRACES:  CREATED  TO  WAIT 


This  section  has  the  SMPS-level  traces  that  underly  execution  indicated  by  lines  six 
and  seven  shown  in  section  D.l.  SMPS-level  trace  statement  have  a  line  number,  the  sim¬ 
ulation  time  in  brackets  and  a  message.  The  message  does  not  always  print  object  state. 

1  [0000.0000]  Socrates  CREATED 

2  [0000.0000]  mps  initSend:  PI (Plato) 

3  [0000.0000]  mps  initSend:  PI (Hegel) 

4  [0000.0000]  mps  initSend:  Pl(Decartes) 

5  [0000.0000]  mps  initSend:  PI (Lao  Tsu) 

6  [0000.0000]  mps  initSend:  PI (Socrates) 

7  [0000.0000]  mps  starting  activators 

8  [0000.0000]  MpsTimer  sending  cp.mps . MpsTimer$THl  to  TIMER  t:0.0 

9  [0000.0000]  mps  starting  activator  0 

10  [0000.0000]  MpsActivatorO  TH1  to  MpsActivatorO  S [CREATED,  BLOCKED] 
p:9  t:0.0  delivered 

11  [0000.0000]  MpsActivatorO  EXECUTING  STARTING-action  [READY]  P:9 

12  [0000.0000]  MpsTimer  executing  STARTING  [READY]  pri:10 

13  [0000.0000]  MpsTimer  sending  TH2  to  MpsTimer  S [STARTING, READY]  t:- 

1.0 

14  [0000.0000]  MpsTimer  executing  CTXSW_T0_RUNNING1  [RUNNING]  pri:10 

15  [0000.7000]  MpsTimer  executing  GETTING_MSG  [RUNNING]  pri:10 

16  [0000.7000]  MpsTimer  executing  WAITING_FOR_MSG  [BLOCKED]  pri:10 

17  [0000.7000]  MpsActivatorO  sending  TH2  to  MpsActivatorO  S [START¬ 

ING,  READY]  p : 9  t : -1 . 0 

18  [0000.7000]  MpsActivatorO  TH2  to  MpsActivatorO  S [STARTING, READY] 
p:9  t:-1.0  delivered 

19  [0000.7000]  MpsActivatorO  EXECUTING  CTXSW  TO  RUNNINGl-action  [RUN¬ 
NING]  P:  9  -  ~ 

20  [0000.7000]  MpsActivatorO  delayedDelivery  1.4 

21  [0001.4000]  MpsActivatorO  TH3  to  .MpsActivatorO 

S[CTXSW_T0_RUNNING1, RUNNING]  p:9  t:1.4  delivered 

22  [0001.4000]  MpsActivatorO  EXECUTING  GETTING  MSG-action  [RUNNING] 

P:  10 

23  [0001.4000]  MpsActivatorO  CHARGING  0.0016897916793823242 

24  [0001.4000]  MpsActivatorO  delayedDelivery  1.4016897916793822 

25  [0001.4017]  MpsActivatorO  TH3  to  MpsActivatorO  S [GETTING  MSG, RUN¬ 
NING]  p : 10  t: 1.4016897916793822  delivered 

26  [0001.4017]  MpsActivatorO  EXECUTING  ACTIVATE-action  [RUNNING]  P:10 

27  [0001.4017]  Plato  WAITING:  %g  TK_A1 (Plato)  to  Token  A 
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